Наш постоянный читатель Сергей обратил внимание на статью Michael Schroeder о том, куда переехали основные онлайн-ресурсы VMware после интеграции с Broadcom.

1. Техническая документация

C 1 января 2025 года техническая документация сайта docs.vmware.com была перемещена на ресурс techdocs.broadcom.com:

Этот сайт содержит не только документацию по продуктам VMware, но и по другим решениям Broadcom. Сайт жутко неудобен, продукты надо как-то искать в поисковой строке, при этом в результатах не всегда можно найти то, что было нужно. Также ранее для документации VMware был доступен экспорт статьи в PDF, теперь же эта возможность отсутствует.

2. Максимумы конфигурации

Сайт configmax.vmware.com переехал на ресурс compatibilityguide.broadcom.com. Тут вроде все как прежде, ничего пока не поломали:

3. Списки совместимости оборудования (HCL)

Списки VMware Hardware Compatibility Lists (HCL) теперь располагаются по адресу compatibilityguide.broadcom.com. Тут в принципе выглядит это все неплохо:

4. Технический ресурс VMware Core

Один из самых полезных ресурсов VMware Core (core.vmware.com) компания Broadcom просто прикончила - теперь по этой ссылке редиректит по адресу vmware.com/resources/resource-center. На этом ресурсе теперь хрен что найдешь - раздел поиска неинтуитивен. Сейчас хоть поправили названия продуктов, а то раньше вместо NSX надо было искать в категории "Networking by NSX", а vSAN - в разделе "Storage by vSAN".

5. Ресурс для разработчиков

Сайт code.vmware.com теперь находится по адресу community.broadcom.com/vmware-code/home. Тут тоже выглядит все как-то аляповато, но про детали могут рассказать только сами разработчики:

Некоторое время назад Вильям Лам поделился решением, позволяющим установить VIB-пакет в сборке для Nested ESXi при использовании vSAN Express Storage Architecture (ESA) и VMware Cloud Foundation (VCF), чтобы обойти предварительную проверку на соответствие списку совместимого оборудования vSAN ESA (HCL) для дисков vSAN ESA.

Хотя в большинстве случаев Вильям использует Nested ESXi для тестирования, недавно он развернул физическую среду VCF. Из-за ограниченного количества NVMe-устройств он хотел использовать vSAN ESA для домена управления VCF, но, конечно же, столкнулся с той же проверкой сертифицированных дисков vSAN ESA, которая не позволяла установщику продолжить процесс.

Вильям надеялся, что сможет использовать метод эмуляции для физического развертывания. Однако после нескольких попыток и ошибок он столкнулся с нестабильным поведением. Пообщавшись с инженерами, он выяснил, что существующее решение также применимо к физическому развертыванию ESXi, поскольку аппаратные контроллеры хранилища скрываются методом эмуляции. Если в системе есть NVMe-устройства, совместимые с vSAN ESA, предварительная проверка vSAN ESA HCL должна пройти успешно, что позволит продолжить установку.

Вильям быстро переустановил последнюю версию ESXi 8.0 Update 3b на одном из своих физических серверов, установил vSAN ESA Hardware Mock VIB и, используя последнюю версию VCF 5.2.1 Cloud Builder, успешно прошел предварительную проверку vSAN ESA, после чего развертывание началось без проблем!

Отлично, что теперь это решение работает как для физических, так и для вложенных (nested) ESXi при использовании с VCF, особенно для создания демонстрационных сред (Proof-of-Concept)!

Примечание: В интерфейсе Cloud Builder по-прежнему выполняется предварительная проверка физических сетевых адаптеров, чтобы убедиться, что они поддерживают 10GbE или более. Таким образом, хотя проверка совместимости vSAN ESA HCL пройдет успешно, установка все же завершится с ошибкой при использовании UI.

Обходной путь — развернуть домен управления VCF с помощью Cloud Builder API, где проверка на 10GbE будет отображаться как предупреждение, а не как критическая ошибка, что позволит продолжить развертывание. Вы можете использовать этот короткий PowerShell-скрипт для вызова Cloud Builder API, а затем отслеживать процесс развертывания через UI Cloud Builder.

$cloudBuilderIP = "192.168.30.190"
$cloudBuilderUser = "admin"
$cloudBuilderPass = "VMware123!"
$mgmtDomainJson = "vcf50-management-domain-example.json"

#### DO NOT EDIT BEYOND HERE ####

$inputJson = Get-Content -Raw $mgmtDomainJson

$pwd = ConvertTo-SecureString $cloudBuilderPass -AsPlainText -Force
$cred = New-Object Management.Automation.PSCredential ($cloudBuilderUser,$pwd)

$bringupAPIParms = @{
    Uri         = "https://${cloudBuilderIP}/v1/sddcs"
    Method      = 'POST'
    Body        = $inputJson
    ContentType = 'application/json'
    Credential = $cred
}

$bringupAPIReturn = Invoke-RestMethod @bringupAPIParms -SkipCertificateCheck

Write-Host "Open browser to the VMware Cloud Builder UI to monitor deployment progress ..."

В этой статье мы обобщим лучшие практики использования платформы VMware vSAN, которые нужно применять для первоначального планирования инфраструктуры отказоустойчивых хранилищ. VMware vSAN имеет некоторые минимальные требования для создания кластера, но этих требований достаточно только при создании кластера для малого бизнеса, когда там не требуется высокая степень доступности данных и сервисов. Давайте рассмотрим требования и лучшие практики платформы vSAN, охватывающие диапазон от малого до корпоративного уровня.

Количество хостов в кластере

Количество хостов в кластере VMware vSAN напрямую влияет на масштабируемость, производительность и отказоустойчивость. Минимальные требования тут такие:

• Кластер из 2 хостов — минимальная конфигурация, поддерживаемая внешней witness-машиной для обеспечения кворума. Такая настройка является экономичной, но не обладает продвинутыми функциями и масштабируемостью.
• Кластер из 3 хостов — устраняет необходимость в выделенном witness-узле и обеспечивает базовую избыточность с использованием RAID 1.

Несмотря на эти минимальные требования, VMware рекомендует использовать не менее 4 хостов для производственных сред. Кластер из 4 и более хостов позволяет использовать конфигурации RAID 5 и RAID 6, обеспечивая защиту до двух отказов одновременно (в этом случае потребуется больше 4 хостов ESXi) и поддерживая операции обслуживания отдельных хостов ESXi без потери доступности машин кластера.

• Используйте не менее 4-х хостов для производственной среды, чтобы обеспечить отказоустойчивость и надежность.
• Для критически важных нагрузок добавляйте дополнительные хосты ESXi при росте инфраструктуры и обеспечивайте дополнительную резервную емкость на случай отказов.

Если вы хотите использовать RAID 5/6 в кластере vSAN, то вам нужно принять во внимание требования к количеству хостов ESXi, которые минимально (и рекомендуемо) вам потребуются, чтобы удовлетворять политике FTT (Failures to tolerate):

Домены отказов (Fault Domains)

Домены отказов являются ключевым элементом повышения отказоустойчивости в vSAN, так как они позволяют интеллектуально распределять данные между хостами, чтобы выдерживать отказы, затрагивающие несколько компонентов (например, стойки или источники питания).

Домен отказов — это логическая группа хостов в кластере vSAN. По умолчанию vSAN рассматривает каждый хост как отдельный домен отказов. Однако в крупных развертываниях администраторы могут вручную настроить домены отказов, чтобы защитить данные от отказов, связанных со стойками или электропитанием.

В больших кластерах сбой всей стойки (или группы хостов) может привести к потере данных, если домены отказов не настроены. Например:

• Без доменов отказов: vSAN может сохранить все реплики объекта на хостах внутри одной стойки, что приведет к риску потери данных в случае выхода стойки из строя.
• С доменами отказов: vSAN распределяет реплики данных между разными стойками, значительно повышая защиту данных.

• Соответствие физической инфраструктуре: создавайте домены отказов на основе стоек, подключений источников питания или сетевого сегментирования.
• Минимальные требования: для обеспечения производственной отказоустойчивости доменов требуется как минимум 3 домена отказов.
• Размер кластера:
  • Для 6-8 хостов — настройте как минимум 3 домена отказов.
  • Для кластеров с 9 и более хостами — используйте 4 и более домена отказов для оптимальной защиты.
• Тестирование и валидация: регулярно проверяйте конфигурацию доменов отказов, чтобы убедиться, что она соответствует политикам vSAN.

Архитектура дисковых групп vSAN OSA

Группы дисков (disk groups) являются строительными блоками хранилища VMware vSAN в архитектуре vSAN OSA. В архитектуре vSAN ESA дисковых групп больше нет (вместо них появился объект Storage Pool).

Дисковые группы vSAN OSA состоят из:

• Яруса кэширования (Caching Tier): нужны для ускорения операций ввода-вывода.
• Яруса емкости (Capacity Tier): хранит постоянные данные виртуальных машин.

Ярус кэширования улучшает производительность чтения и записи. Для кэширования рекомендуется использовать диски NVMe или SSD, особенно в полностью флэш-конфигурациях (All-Flash).

• Выделяйте примерно 10% от общего объема VMDK-дисков машин для яруса кэширования в гибридных конфигурациях vSAN, однако при этом нужно учесть параметр политики FTT. Более подробно об этом написано тут. Для All-Flash конфигураций такой рекомендации нет, размер кэша на запись определяется профилем нагрузки (кэша на чтение там нет).
• Используйте NVMe-диски корпоративного класса для высокопроизводительных нагрузок.

Ярус емкости содержит основную часть данных и критически важен для масштабируемости. Полностью флэш-конфигурации (All-Flash) обеспечивают максимальную производительность, тогда как гибридные конфигурации (hybrid) являются более экономичным решением для менее требовательных нагрузок.

• Используйте полностью флэш-конфигурации для приложений, чувствительных к задержкам (latency).
• Включайте дедупликацию и сжатие данных для оптимизации дискового пространства. При этом учтите требования и характер нагрузки - если у вас write-intensive нагрузка, то включение дедупликации может привести к замедлению работы системы.

Добавление нескольких групп дисков на каждом хосте улучшает отказоустойчивость и производительность.

• Настройте не менее двух групп дисков на хост.
• Равномерно распределяйте рабочие нагрузки между группами дисков, чтобы избежать узких мест.

VMware vSAN и блочные хранилища

Решения для организации блочных хранилищ, такие как Dell PowerStore и Unity, остаются популярными для традиционных ИТ-нагрузок. Вот как они выглядят в сравнении с vSAN:

Сильные и слабые стороны

Преимущества vSAN:

• Глубокая интеграция с vSphere упрощает развертывание и управление.
• Гибкость масштабирования за счет добавления хостов, а не выделенных массивов хранения.
• Поддержка снапшотов и репликации для архитектуры vSAN ESA.
• Экономически выгоден для организаций, уже использующих VMware.

• Зависимость от аппаратных ресурсов на уровне отдельных хостов, что может ограничивать масштабируемость.
• Производительность может снижаться при некорректной конфигурации.

Преимущества блочного хранилища:

• Высокая производительность для нагрузок с высокими IOPS, таких как транзакционные базы данных. При этом надо учесть, что vSAN также может обеспечивать высокую производительность при использовании соответствующего оборудования на правильно подобранном количестве хостов кластера.
• Развитые функции, такие как снапшоты и репликация (с поддержкой на аппаратном уровне).

Недостатки блочного хранилища:

• Меньшая гибкость по сравнению с гиперконвергентными решениями.
• Более высокая стоимость и сложность при первоначальном развертывании. Однако также нужно учитывать и политику лицензирования Broadcom/VMware, где цена входа также может оказаться высокой (см. комментарий к этой статье).

Развертывание баз данных на VMware vSAN

Базы данных создают сложные паттерны ввода-вывода, требующие низкой задержки (latency) и высокой пропускной способности (throughput). vSAN удовлетворяет этим требованиям за счет кэширования и конфигураций RAID.

Политики хранения (Storage Policies)

Политики хранения vSAN позволяют точно контролировать производительность и доступность баз данных.

Лучшие практики:

• Настройте параметр FTT (Failures to Tolerate) = 2 для критически важных баз данных.
• Используйте RAID 5 или RAID 6 для экономии емкостей при защите данных, если вас устраивает производительность и latency.

Регулярный мониторинг помогает поддерживать оптимальную производительность баз данных. Используйте продукт vRealize Operations для отслеживания таких метрик, как IOPS и latency.

Дункану Эппингу задали интересный вопрос: учитываются ли файлы, хранящиеся на общих хранилищах vSAN с включенным vSAN File Services, в максимальном количестве объектов (max object count)? Поскольку Дункан не обсуждал это в последние несколько лет, он решил сделать краткое напоминание.

С vSAN File Services файлы, которые пользователи хранят в своем файловом хранилище, размещаются внутри объекта vSAN. Сам объект учитывается при подсчёте максимального количества компонентов в кластере, но отдельные файлы в нем - конечно же, нет.

Что касается vSAN File Services, то для каждого созданного файлового хранилища необходимо выбрать политику. Эта политика будет применяться к объекту, который создаётся для файлового хранилища. Каждый объект, как и для дисков виртуальных машин, состоит из одного или нескольких компонентов. Именно эти компоненты и будут учитываться при подсчёте максимального количества компонентов, которое может быть в кластере vSAN.

Для одного узла vSAN ESA максимальное количество компонентов составляет 27 000, а для vSAN OSA – 9 000 компонентов на хост. Имейте в виду, что, например, RAID-1 и RAID-6 используют разное количество компонентов. Однако, как правило, это не должно быть большой проблемой для большинства клиентов, если только у вас не очень большая инфраструктура (или наоборот, небольшая, но вы на пределе возможностей по количеству хранилищ и т. д.).

В видео ниже показана демонстрация, которую Дункан проводил несколько лет назад, где исследуются эти компоненты в интерфейсе vSphere Client и с помощью CLI:

Компания VMware представила видео "VCF Cloud Console Migration Overview of changes", в котором описываются будущие нововведения для сервис-провайдеров по программе VCPP, которых переведут на новую объединенную консоль VCF Cloud Console, приходящую на смену VCPP Cloud Console.

В видео представлен обзор изменений, которые в ближайшие месяцы будут внедрены в облачный консольный сервис VMware (VCF Business Services). Автор, Алиса Мотри, рассказывает о миграции текущих консолей, таких как cloud.vmware.com, VCPP Cloud Console и usage meters, в новый сервис VCF Business Services Console.

Ключевые моменты:

1. Текущая и будущая архитектуры:
   Текущая система, где сайты и порталы для управления контрактами и лицензиями функционируют независимо, будет заменена на единую архитектуру. В новой системе каждый сайт с активным контрактом будет напрямую связан с VCF Business Services Console.
2. Миграция пользователей:
   Пользователи из текущих организаций VCPP Cloud Console будут перенесены в новый сервис с сохранением их ролей и разрешений. Это позволит минимизировать сбои в работе партнеров.
3. Миграция Usage meters:
   Активные Usage meters, передающие данные о лицензиях Broadcom, также будут перенесены в новую консоль вместе с их отчетами. Usage meters, работающие только с лицензиями VMware, миграции не подлежат.
4. Интеграция через API:
   Партнеры смогут взаимодействовать с новой консолью через API. Однако приложения OAuth, созданные в старой системе, не подлежат переносу, и их потребуется настроить заново.
5. Действия для партнеров:
   Если Usage meters зарегистрированы в нескольких организациях VCPP, рекомендуется связаться с техподдержкой для их объединения перед миграцией.

Эти изменения направлены на упрощение управления и повышения интеграции между сервисами VMware для партнеров.

Pete Del Vecchio, Data Center Switch Product Line Manager в компании Broadcom, выпустил интересное видео, в котором он высказывает свои предположения касательно развития сетевой инфраструктуры в 2025 году:

1. Переход от InfiniBand к Ethernet для крупных GPU-кластеров:
   Broadcom прогнозирует, что в 2025 году все крупные гипермасштабируемые GPU-кластеры окончательно перейдут с технологии InfiniBand на Ethernet. Уже сейчас большинство объявленных продуктов и кластеров для GPU используют Ethernet, и эта тенденция продолжится.
2. Ethernet станет стандартом для масштабируемых сетей (Scale-Up):
   Ethernet не только заменит InfiniBand в сетях Scale-Out (соединения между GPU-узлами), но и станет основой для сетей Scale-Up, обеспечивая связи внутри отдельных GPU-систем. В 2025 году ожидаются новые продукты и системы GPU на основе Ethernet для этих задач.
3. Демократизация искусственного интеллекта (AI):
   Broadcom считает, что AI станет доступнее для компаний разного масштаба, а не только для крупных гипермасштабируемых компаний. Основой для этого будет использование более эффективных процессоров и сетевых технологий от различных производителей. Broadcom видит свою роль в создании высокоэффективных сетевых решений, поддерживающих распределённые системы для обучения и работы AI.

Роль Broadcom заключается в активном участии в переходе на Ethernet, разработке решений для масштабируемых сетей и создании технологий, способствующих демократизации AI.

Блогер Эрик Слуф опубликовал интересные 30-секундные видео в формате Youtube Shorts, посвященные платформе VMware Cloud Foundation.

Ролики очень удобно смотреть с телефона:

• Workload Domain Types - Management
• Workload Domain Types - VI Workload
• Single Instance - Single Availability Zone
• Single Instance - Multiple Availability Zones
• Multiple Instances - Single Availability Zone per Instance
• Multiple Instances - Multiple Availability Zones per Instance

Интересный пост, касающийся использования виртуальных хранилищ NFS (в формате Virtual Appliance) на платформе vSphere и их производительности, опубликовал Marco Baaijen в своем блоге. До недавнего времени он использовал центральное хранилище Synology на основе NFSv3 и две локально подключенные PCI флэш-карты. Однако из-за ограничений драйверов он был вынужден использовать ESXi 6.7 на одном физическом хосте (HP DL380 Gen9). Желание перейти на vSphere 8.0 U3 для изучения mac-learning привело тому, что он больше не мог использовать флэш-накопители в качестве локального хранилища для размещения вложенных виртуальных машин. Поэтому Марко решил использовать эти флэш-накопители на отдельном физическом хосте на базе ESXi 6.7 (HP DL380 G7).

Теперь у нас есть хост ESXi 8 и и хост с версией ESXi 6.7, которые поддерживают работу с этими флэш-картами. Кроме того, мы будем использовать 10-гигабитные сетевые карты (NIC) на обоих хостах, подключив порты напрямую. Марко начал искать бесплатное, удобное и функциональное виртуальное NAS-решение. Рассматривал Unraid (не бесплатный), TrueNAS (нестабильный), OpenFiler/XigmaNAS (не тестировался) и в итоге остановился на OpenMediaVault (с некоторыми плагинами).

И вот тут начинается самое интересное. Как максимально эффективно использовать доступное физическое и виртуальное оборудование? По его мнению, чтение и запись должны происходить одновременно на всех дисках, а трафик — распределяться по всем доступным каналам. Он решил использовать несколько паравиртуальных SCSI-контроллеров и настроить прямой доступ (pass-thru) к портам 10-гигабитных NIC. Всё доступное пространство флэш-накопителей представляется виртуальной машине как жесткий диск и назначается по круговому принципу на доступные SCSI-контроллеры.

В OpenMediaVault мы используем плагин Multiple-device для создания страйпа (striped volume) на всех доступных дисках.

На основе этого мы можем создать файловую систему и общую папку, которые в конечном итоге будут представлены как экспорт NFS (v3/v4.1). После тестирования стало очевидно, что XFS лучше всего подходит для виртуальных нагрузок. Для NFS Марко решил использовать опции async и no_subtree_check, чтобы немного увеличить скорость работы.

Теперь переходим к сетевой части, где автор стремился использовать оба 10-гигабитных порта сетевых карт (X-соединённых между физическими хостами). Для этого он настроил следующее в OpenMediaVault:

С этими настройками серверная часть NFS уже работает. Что касается клиентской стороны, Марко хотел использовать несколько сетевых карт (NIC) и порты vmkernel, желательно на выделенных сетевых стэках (Netstacks). Однако, начиная с ESXi 8.0, VMware решила отказаться от возможности направлять трафик NFS через выделенные сетевые стэки. Ранее для этого необходимо было создать новые стэки и настроить SunRPC для их использования. В ESXi 8.0+ команды SunRPC больше не работают, так как новая реализация проверяет использование только Default Netstack.

Таким образом, остаётся использовать возможности NFS 4.1 для работы с несколькими соединениями (parallel NFS) и выделения трафика для портов vmkernel. Но сначала давайте посмотрим на конфигурацию виртуального коммутатора на стороне NFS-клиента. Как показано на рисунке ниже, мы создали два раздельных пути, каждый из которых использует выделенный vmkernel-порт и собственный физический uplink-NIC.

Первое, что нужно проверить, — это подключение между адресами клиента и сервера. Существуют три способа сделать это: от простого до более детального.

[root@mgmt01:~] esxcli network ip interface list
---
vmk1
   Name: vmk1
   MAC Address: 00:50:56:68:4c:f3
   Enabled: true
   Portset: vSwitch1
   Portgroup: vmk1-NFS
   Netstack Instance: defaultTcpipStack
   VDS Name: N/A
   VDS UUID: N/A
   VDS Port: N/A
   VDS Connection: -1
   Opaque Network ID: N/A
   Opaque Network Type: N/A
   External ID: N/A
   MTU: 9000
   TSO MSS: 65535
   RXDispQueue Size: 4
   Port ID: 134217815

vmk2
   Name: vmk2
   MAC Address: 00:50:56:6f:d0:15
   Enabled: true
   Portset: vSwitch2
   Portgroup: vmk2-NFS
   Netstack Instance: defaultTcpipStack
   VDS Name: N/A
   VDS UUID: N/A
   VDS Port: N/A
   VDS Connection: -1
   Opaque Network ID: N/A
   Opaque Network Type: N/A
   External ID: N/A
   MTU: 9000
   TSO MSS: 65535
   RXDispQueue Size: 4
   Port ID: 167772315

[root@mgmt01:~] esxcli network ip netstack list defaultTcpipStack
   Key: defaultTcpipStack
   Name: defaultTcpipStack
   State: 4660

[root@mgmt01:~] ping 10.10.10.62
PING 10.10.10.62 (10.10.10.62): 56 data bytes
64 bytes from 10.10.10.62: icmp_seq=0 ttl=64 time=0.219 ms
64 bytes from 10.10.10.62: icmp_seq=1 ttl=64 time=0.173 ms
64 bytes from 10.10.10.62: icmp_seq=2 ttl=64 time=0.174 ms

--- 10.10.10.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.173/0.189/0.219 ms

[root@mgmt01:~] ping 172.16.0.62
PING 172.16.0.62 (172.16.0.62): 56 data bytes
64 bytes from 172.16.0.62: icmp_seq=0 ttl=64 time=0.155 ms
64 bytes from 172.16.0.62: icmp_seq=1 ttl=64 time=0.141 ms
64 bytes from 172.16.0.62: icmp_seq=2 ttl=64 time=0.187 ms

--- 172.16.0.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.141/0.161/0.187 ms

root@mgmt01:~] vmkping -I vmk1 10.10.10.62
PING 10.10.10.62 (10.10.10.62): 56 data bytes
64 bytes from 10.10.10.62: icmp_seq=0 ttl=64 time=0.141 ms
64 bytes from 10.10.10.62: icmp_seq=1 ttl=64 time=0.981 ms
64 bytes from 10.10.10.62: icmp_seq=2 ttl=64 time=0.183 ms

--- 10.10.10.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.141/0.435/0.981 ms

[root@mgmt01:~] vmkping -I vmk2 172.16.0.62
PING 172.16.0.62 (172.16.0.62): 56 data bytes
64 bytes from 172.16.0.62: icmp_seq=0 ttl=64 time=0.131 ms
64 bytes from 172.16.0.62: icmp_seq=1 ttl=64 time=0.187 ms
64 bytes from 172.16.0.62: icmp_seq=2 ttl=64 time=0.190 ms

--- 172.16.0.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.131/0.169/0.190 ms

[root@mgmt01:~] esxcli network diag ping --netstack defaultTcpipStack -I vmk1 -H 10.10.10.62
   Trace: 
         Received Bytes: 64
         Host: 10.10.10.62
         ICMP Seq: 0
         TTL: 64
         Round-trip Time: 139 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 10.10.10.62
         ICMP Seq: 1
         TTL: 64
         Round-trip Time: 180 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 10.10.10.62
         ICMP Seq: 2
         TTL: 64
         Round-trip Time: 148 us
         Dup: false
         Detail: 
   Summary: 
         Host Addr: 10.10.10.62
         Transmitted: 3
         Received: 3
         Duplicated: 0
         Packet Lost: 0
         Round-trip Min: 139 us
         Round-trip Avg: 155 us
         Round-trip Max: 180 us

[root@mgmt01:~] esxcli network diag ping --netstack defaultTcpipStack -I vmk2 -H 172.16.0.62
   Trace: 
         Received Bytes: 64
         Host: 172.16.0.62
         ICMP Seq: 0
         TTL: 64
         Round-trip Time: 182 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 172.16.0.62
         ICMP Seq: 1
         TTL: 64
         Round-trip Time: 136 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 172.16.0.62
         ICMP Seq: 2
         TTL: 64
         Round-trip Time: 213 us
         Dup: false
         Detail: 
   Summary: 
         Host Addr: 172.16.0.62
         Transmitted: 3
         Received: 3
         Duplicated: 0
         Packet Lost: 0
         Round-trip Min: 136 us
         Round-trip Avg: 177 us
         Round-trip Max: 213 us

С этими положительными результатами мы теперь можем подключить NFS-ресурс, используя несколько подключений на основе vmk, и убедиться, что всё прошло успешно.

[root@mgmt01:~] esxcli storage nfs41 add --connections=8 --host-vmknic=10.10.10.62:vmk1,172.16.0.62:vmk2 --share=/fio-folder --volume-name=fio

[root@mgmt01:~] esxcli storage nfs41 list
Volume Name  Host(s)                  Share        Vmknics    Accessible  Mounted  Connections  Read-Only  Security   isPE  Hardware Acceleration
-----------  -----------------------  -----------  ---------  ----------  -------  -----------  ---------  --------  -----  ---------------------
fio          10.10.10.62,172.16.0.62  /fio-folder  vmk1,vmk2        true     true            8      false  AUTH_SYS  false  Not Supported

[root@mgmt01:~] esxcli storage nfs41 param get -v all
Volume Name  MaxQueueDepth  MaxReadTransferSize  MaxWriteTransferSize  Vmknics    Connections
-----------  -------------  -------------------  --------------------  ---------  -----------
fio             4294967295               261120                261120  vmk1,vmk2            8

Наконец, мы проверяем, что оба подключения действительно используются, доступ к дискам осуществляется равномерно, а производительность соответствует ожиданиям (в данном тесте использовалась миграция одной виртуальной машины с помощью SvMotion). На стороне NAS-сервера Марко установил net-tools и iptraf-ng для создания приведённых ниже скриншотов с данными в реальном времени. Для анализа производительности флэш-дисков на физическом хосте использовался esxtop.

root@openNAS:~# netstat | grep nfs
tcp        0    128 172.16.0.62:nfs         172.16.0.60:623         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:617         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:616         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:621         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:613         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:620         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:610         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:611         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:615         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:619         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:609         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:614         ESTABLISHED
tcp        0      0 172.16.0.62:nfs         172.16.0.60:618         ESTABLISHED
tcp        0      0 172.16.0.62:nfs         172.16.0.60:622         ESTABLISHED
tcp        0      0 172.16.0.62:nfs         172.16.0.60:624         ESTABLISHED
tcp        0      0 10.10.10.62:nfs         10.10.10.60:612         ESTABLISHED

По итогам тестирования NFS на ESXi 8 Марко делает следующие выводы:

• NFSv4.1 превосходит NFSv3 по производительности в 2 раза.
• XFS превосходит EXT4 по производительности в 3 раза (ZFS также был протестирован на TrueNAS и показал отличные результаты при последовательных операциях ввода-вывода).
• Клиент NFSv4.1 в ESXi 8.0+ не может быть привязан к выделенному/отдельному сетевому стэку (Netstack).
• Использование нескольких подключений NFSv4.1 на основе выделенных портов vmkernel работает очень эффективно.
• Виртуальные NAS-устройства демонстрируют хорошую производительность, но не все из них стабильны (проблемы с потерей NFS-томов, сообщения об ухудшении производительности NFS, увеличении задержек ввода-вывода).

В прошлом году Вильям Лам продемонстрировал метод настройки строки железа SMBIOS с использованием Nested ESXi, но решение было далеко от идеала: оно требовало модификации ROM-файла виртуальной машины и ограничивалось использованием BIOS-прошивки для машины Nested ESXi, в то время как поведение с EFI-прошивкой отличалось.

В конце прошлого года Вильям проводил исследования и наткнулся на гораздо более изящное решение, которое работает как для физического, так и для виртуального ESXi. Существует параметр ядра ESXi, который можно переключить, чтобы просто игнорировать стандартный SMBIOS оборудования, а затем эмулировать собственную пользовательскую информацию SMBIOS.

Итак, давайте попробуем задать кастомные аппаратные настройки SMBIOS.

Шаг 1 – Подключитесь по SSH к вашему ESXi-хосту, отредактируйте файл конфигурации /bootbank/boot.cfg и добавьте ignoreHwSMBIOSInfo=TRUE в строку kernelopt, после чего перезагрузите систему.

Шаг 2 – Далее нам нужно выполнить команду vsish, чтобы настроить желаемую информацию SMBIOS. Однако, вместо того чтобы заставлять пользователей вручную создавать команду, Вильям создал простую функцию PowerShell, которая сделает процесс более удобным.

Сохраните или выполните приведенный ниже фрагмент PowerShell-кода, который определяет новую функцию Generate-CustomESXiSMBIOS. Эта функция принимает следующие шесть аргументов:

• Uuid – UUID, который будет использоваться в симулированной информации SMBIOS.
• Model – название модели.
• Vendor – наименование производителя.
• Serial – серийный номер.
• SKU – идентификатор SKU.
• Family – строка семейства.

Function Generate-CustomESXiSMBIOS {
    param(
        [Parameter(Mandatory=$true)][String]$Uuid,
        [Parameter(Mandatory=$true)][String]$Model,
        [Parameter(Mandatory=$true)][String]$Vendor,
        [Parameter(Mandatory=$true)][String]$Serial,
        [Parameter(Mandatory=$true)][String]$SKU,
        [Parameter(Mandatory=$true)][String]$Family
    )

    $guid = [Guid]$Uuid

    $guidBytes = $guid.ToByteArray()
    $decimalPairs = foreach ($byte in $guidBytes) {
        "{0:D2}" -f $byte
    }
    $uuidPairs = $decimalPairs -join ', '

    Write-Host -ForegroundColor Yellow "`nvsish -e set /hardware/bios/dmiInfo {\`"${Model}\`", \`"${Vendor}\`", \`"${Serial}\`", [${uuidPairs}], \`"1.0.0\`", 6, \`"SKU=${SKU}\`", \`"${Family}\`"}`n"
}

Вот пример использования функции для генерации команды vsish:

Generate-CustomESXiSMBIOS -Uuid "43f32ef6-a3a8-44cb-9137-31cb4c6c520a" -Model "WilliamLam HAL9K" -Vendor "WilliamLam.com" -Serial "HAL-9000" -SKU "H9K" -Family "WilliamLam"

Шаг 3 – После того как вы получите сгенерированную команду, выполните её на вашем хосте ESXi, как показано на скриншоте ниже:

vsish -e set /hardware/bios/dmiInfo {\"WilliamLam HAL9K\", \"WilliamLam.com\", \"HAL-9000\", [246, 46, 243, 67, 168, 163, 203, 68, 145, 55, 49, 203, 76, 108, 82, 10], \"1.0.0\", 6, \"SKU=H9K\", \"WilliamLam\"}

Вам потребуется перезапустить службу hostd, чтобы информация стала доступной. Для этого выполните команду:

/etc/init.d/hostd restart

Если вы теперь войдете в ESXi Host Client, vCenter Server или vSphere API (включая PowerCLI), то обнаружите, что производитель оборудования, модель, серийный номер и UUID отображают заданные вами пользовательские значения, а не данные реального физического оборудования!

Пользовательский SMBIOS не сохраняется после перезагрузки, поэтому вам потребуется повторно запускать команду каждый раз после перезагрузки вашего хоста ESXi.

Не все виртуальные машины на базе vSphere одинаковы, Вильям Лам написал интересный пост об обнаружении ВМ разного типа с помощью PowerCLI. Это особенно актуально с введением vSphere IaaS (ранее известного как vSphere Supervisor, vSphere with Tanzu или Project Pacific), который включает современный способ развертывания традиционных/классических виртуальных машин, а также новый тип виртуальной машины, основанный на контейнерах, известный как vSphere Pod VM.

vSphere Pod - это эквивалент Kubernetes pod в среде VMware Tanzu / vSphere IaaS. Это легковесная виртуальная машина, которая запускает один или несколько контейнеров на базе Linux. Каждый vSphere Pod точно настроен для работы с конкретной нагрузкой и имеет явно указанные reservations для ресурсов этой нагрузки. Он выделяет точное количество хранилища, памяти и процессорных ресурсов, необходимых для работы нагрузки внутри ВМ. vSphere Pods поддерживаются только в случаях, когда компонент Supervisor настроен с использованием NSX в качестве сетевого стека.

Недавно возник вопрос о том, как можно различать традиционные/классические виртуальные машины, созданные через пользовательский интерфейс или API vSphere, и виртуальные машины vSphere Pod средствами PowerCLI, в частности с использованием стандартной команды Get-VM.

Как видно на приведенном выше скриншоте, vSphere может создавать и управлять несколькими типами виртуальных машин, от традиционных/классических, которые мы все знаем последние два десятилетия, специализированных "Сервисных/Агентских" виртуальных машин, управляемых различными решениями VMware или сторонних разработчиков, и до новых виртуальных машин vSphere IaaS и виртуальных машин рабочих нагрузок контейнеров vSphere Pod (которые можно назвать Supervisor VM и Supervisor Pod VM).

Хотя команда Get-VM не различает эти типы виртуальных машин, существует несколько свойств, которые можно использовать в vSphere API для различения этих типов виртуальных машин. Ниже приведен фрагмент кода PowerCLI, который Вильям написал для того, чтобы различать типы виртуальных машин, что может быть полезно для автоматизации и/или отчетности.

$vms = Get-Vm

$results = @()
foreach ($vm in $vms) {
    if($vm.GuestId -eq "crxPod1Guest" -or $vm.GuestId -eq "crxSys1Guest") {
        $vmType = "Supervisor Pod VM"
    } elseif($vm.ExtensionData.Config.ManagedBy -ne $null) {
        switch($vm.ExtensionData.Config.ManagedBy.ExtensionKey) {
            "com.vmware.vim.eam" {$vmType = "EAM Managed VM"}
            "com.vmware.vcenter.wcp" {$vmType = "Supervisor VM"}
            "default" {$vmType = "Other 2nd/3rd Party Managed Classic VM"}
        }
    } else {
        $vmType = "Classic VM"
    }

    $tmp = [pscustomobject] @{
        Name = $vm.Name
        Type = $vmType
    }
    $results+=$tmp
}

$results | FT | Sort-Object -Property Types

Вот пример вывода скрипта для той же среды, что и на скриншоте из пользовательского интерфейса vSphere, но теперь у вас есть способ различать различные типы виртуальных машин, управляемых платформой vSphere.

На конференции VMware Explore 2024 была представлена презентация "Hardening and Securing VMware Cloud Foundation" (#VCFT1616LV), в которой инженер по безопасности и комплаенсу Broadcom Боб Планкерс поделился ключевыми стратегиями и подходами к обеспечению безопасности VMware Cloud Foundation (VCF).

Презентация фокусируется на многоуровневом подходе к защите инфраструктуры VCF, охватывая такие ключевые аспекты, как:

• Основы информационной безопасности: реализация принципов конфиденциальности, целостности и доступности данных.
• Технические меры защиты: использование шифрования данных, проверка подлинности компонентов, функции Secure Boot и другие механизмы.
• Проектирование систем: ранняя интеграция функций безопасности, адаптация к уникальным требованиям каждой организации и применение компенсирующих средств контроля.
• Соответствие стандартам: использование DISA STIG, CIS Benchmarks и других гайдлайнов для минимизации уязвимостей и упрощения аудита.

Одним из главных акцентов стала концепция "Zero Trust", которая предполагает минимизацию доверия ко всем компонентам и пользователям системы. Также рассмотрены стратегии аутентификации и авторизации, включая федерацию идентификаций и внедрение многофакторной аутентификации (MFA).

Презентация содержит и практические рекомендации, такие как:

• Отключение неиспользуемых функций управления серверами (например, IPMI, SSH).
• Настройка безопасной загрузки (UEFI Secure Boot) и использования Trusted Platform Module (TPM).
• Оптимизация управления доступом через модели RBAC и изоляцию критических систем.

Для тех из вас, кто пропустил релиз платформы Windows Server 2025, который состоялся 1 ноября этого года, мы сделали список новых возможностей гипервизора Hyper-V, который постепенно подтягивается к Enterprise-функционалу, но все еще остается нишевым решением. В новой ОС Hyper-V получил ряд значительных улучшений, направленных на повышение производительности, масштабируемости и гибкости виртуализации.

Итак, что нового в платформе виртуализации Hyper-V появилось с релизом Windows Server 2025:

• Поддержка разделения GPU (GPU Partitioning) - теперь можно эффективно распределять вычислительные ресурсы графических процессоров между виртуальными машинами, что позволяет выполнять ресурсоемкие задачи, такие как искусственный интеллект и обработка больших данных, без необходимости выделения отдельного GPU для каждой машины. Также поддерживаются пулы GPU, позволяющие обеспечить высокую доступность виртуальных машин (HA) с использованием дискретного назначения устройств (Discrete Device Assignment, DDA) между хостами.

• Живая миграция виртуальных машин с активными GPU (Live Migration) - добавлена возможность переноса виртуальных машин с задействованными GPU без прерывания их работы, что минимизирует простои при обслуживании серверов.
• Увеличение максимальных ресурсов для виртуальных машин - теперь одна виртуальная машина может использовать до 240 ТБ оперативной памяти и до 2048 виртуальных процессоров, что значительно расширяет возможности для работы с большими вычислительными нагрузками.
• Адаптивное управление сетевым трафиком (Adaptive Traffic Control, ATC) - введена система, которая динамически управляет трафиком между виртуальными машинами, снижая задержки и повышая пропускную способность сети.
• Улучшенная поддержка виртуальных машин второго поколения (Gen 2) - в мастере создания новых виртуальных машин в Hyper-V Manager теперь по умолчанию выбирается поколение 2, что обеспечивает более высокую производительность и безопасность. Образы Azure Marketplace также работают на базе машин нового поколения.
• Dynamic Processor Compatibility – позволяет использовать процессоры разных поколений и получать лучший набор функций, который поддерживается всеми из них.

• Кластеры на основе сертификатов – позволяют создавать "Workgroup Clusters", которые не зависят от Active Directory (AD).
• Повышенная надежность и производительность обновлений с учетом работающих в производственной среде кластеров (Cluster-aware updating).
• Поддержка растянутых кластеров S2D (Storage Spaces Direct stretched cluster).
• Функция Network ATC упрощает настройку сети, позволяя задавать назначение (хранение, сеть, вычисления), а Network HUD имеет функции стабилизации: может изолировать сетевой адаптер при обнаружении нестабильности или физических ошибок из-за совместного использования PCI-ресурсов.
• Возможность SND multi-site обеспечивает подключение уровня L2 или L3 между физическими локациями для виртуализированных рабочих нагрузок и Kubernetes (гибридный AKS). Производительность шлюза SDN улучшена на 20-50%.
• Улучшения поддержки хранилищ NVMe, с полностью переписанным слоем хранения, который обеспечивает на 90% больше IOPS на NVMe SSD. Помимо полностью переписанного хранилища, наконец, появился встроенный инициатор NVMe-oF TCP.

• Улучшения Virtualization-based security (VBS) для помощи приложениям в защите их секретов за счет устранения необходимости доверять администраторам и повышения устойчивости к злонамеренным атакам.
• Горячее обновление запущенного сервера (Hotpatching, требуется управление через Azure Arc) с практически мгновенным применением обновлений и без перезагрузки для физических, виртуальных и облачных серверов Windows.
• Оптимизация выбора сети для живой миграции - улучшена логика определения оптимальной сети между узлами для живой миграции виртуальных машин, что ускоряет процесс и повышает его надежность.
• Поддержка ARM64: Windows Server 2025 стал первой серверной операционной системой Windows с поддержкой архитектуры ARM64, расширяя возможности Hyper-V на новых аппаратных платформах.
• Windows Server 2025 поддерживает множество вариантов хранения данных в корпоративной среде для таких сценариев, как запуск виртуальных машин с использованием Hyper-V. К ним относятся:
  • Автономный сервер с локальным хранилищем, а также NAS или SAN

• Гиперконвергентная инфраструктура

• Масштабируемое хранилище (scale-out storage)

• Функции дедупликации и сжатия, которыми можно управлять с помощью Windows Admin Center или PowerShell. Microsoft отмечает более чем 60% сокращение объема хранения при виртуализации и резервном копировании с использованием дедупликации и сжатия. Эта технология также поддерживает работу с кластерами. Администраторы могут выбрать использование только дедупликации, только сжатия или их совместное использование, которое является конфигурацией по умолчанию. Также доступны два отдельных алгоритма сжатия, которые позволяют регулировать степень агрессивности задач сжатия.

• Тонкое развертывание хранилищ (Thin Provisioning) позволяет гораздо более эффективно настраивать хранилище. Эта технология позволяет администраторам задавать размеры томов и потенциально перераспределять пространство, чтобы удовлетворять определённые требования конфигурации. Емкость может быть увеличена на лету, чтобы соответствовать изменяющимся потребностям. Благодаря более быстрому флэш-хранилищу и NVMe, тонкое развертывание теперь рекомендуется для настройки хранилища. Это позволяет выделить общее пространство, но использовать только фактически записанное место на диске.

• В Windows Server 2025 теперь есть настраиваемые параметры восстановления и ресинхронизации (repair and resynchronization settings). Теперь администраторы могут точно настроить процесс восстановления, что позволяет достичь баланса между поддержанием производительности виртуальных машин и поддержанием целостности данных. Основные моменты:

  • Процессы восстановления и ресинхронизации могут повлиять на виртуальные машины с ограниченными ресурсами.
  • Используя настраиваемые параметры, администраторы могут регулировать скорость через Windows Admin Center или PowerShell.
  • Администраторы могут оптимизировать процесс либо для производительности виртуальных машин, либо для операции восстановления/ресинхронизации.

Вильям Лам выложил интересный сценарий PowerCLI, который поможет вам получить информацию об использовании хранилищ и накладных расходах vSAN с использованием API.

В интерфейсе vSphere Client вы можете увидеть подробный анализ использования хранилища vSAN, включая различные системные накладные расходы, выбрав конкретный кластер vSAN, а затем перейдя в раздел Monitor->vSAN->Capacity, как показано на скриншоте ниже:

Различные конфигурации vSAN, такие как использование традиционной архитектуры хранения vSAN OSA или новой архитектуры vSAN Express Storage Architecture (ESA), а также активация функций, таких как дедупликация и сжатие vSAN, приводят к различным метрикам использования дискового пространства, которые отображаются в разделе информации.

Недавно у Вильяма спросили - а как получить информацию о накладных расходах, связанных с дедупликацией и сжатием vSAN, с использованием PowerCLI?

Хотя командлет PowerCLI vSAN Get-VsanSpaceUsage предоставляет множество метрик использования, отображаемых в интерфейсе vSphere, он не раскрывает все свойства.

Тем не менее, мы можем использовать PowerCLI для получения этой информации, используя базовый метод vSAN API, который предоставляет эти данные, в частности querySpaceUsage(). Как видно из документации по API, этот метод возвращает массив объектов типов использования vSAN, которые соответствуют данным, отображаемым в интерфейсе vSphere, с расшифровкой свойства ObjType.

Чтобы продемонстрировать использование этого API, Вильям создал пример PowerCLI-скрипта под названием vsanUsageAndOverheadInfo.ps1, в котором вам нужно просто обновить переменную $vsanCluster, указав имя нужного кластера vSAN.

После подключения к серверу vCenter вы можете просто выполнить этот скрипт, как показано ниже:

./vsanUsageAndOverheadInfo.ps1

Вывод будет выглядеть вот так:

Windows 11 предъявляет строгие требования к аппаратному обеспечению, включая наличие устройства Trusted Platform Module (TPM) версии 2.0. Для запуска Windows 11 в виртуальной среде VMware vSphere необходимо использовать виртуальный TPM-модуль (vTPM).

В целом, установка Windows 11 ничем не отличается от установки других ОС в VMware vSphere или Workstation:

Настройка vSphere для поддержки Windows 11

Для добавления vTPM в виртуальные машины требуется настройка провайдера ключей (Key Provider). Если вы видите предупреждение, приведенное ниже, это означает, что провайдер ключей не настроен:

Microsoft Windows 11 (64-bit) requires a Virtual TPM device, which cannot be added to this virtual machine because the Sphere environment is not configured with a key provider.

На платформе vSphere в качестве провайдера ключей может быть встроенный Native Key Provider или сторонний провайдер ключей. Native Key Provider поддерживается, начиная с версии vSphere 7 Update 2. Более подробная информация о его настройке приведена тут.

Основные шаги:

1. Настройте Native Key Provider через vSphere Client, если необходимо.
2. Шифрование файлов ВМ: файлы домашней директории ВМ (память, swap, NVRAM) будут зашифрованы автоматически при использовании vTPM. Полное шифрование диска не требуется.
3. Подключение vTPM: добавьте виртуальный TPM через мастер создания ВМ (если он отсутствует) или обновите существующую ВМ.

Установка Windows 11 в виртуальной машине

Установка на vSphere 8:

1. Создайте новую виртуальную машину с совместимостью ESXi 8.0 и выше (hardware version 20).
2. Выберите Microsoft Windows 11 (64-bit) в качестве версии ОС.
3. Если отображается ошибка о необходимости настройки Key Provider, выполните настройку согласно рекомендациям выше.
4. Завершите мастер создания ВМ и установите Windows 11 как обычно.

Установка на vSphere 7:

1. Создайте новую виртуальную машину с совместимостью ESXi 6.7 U2 и выше (hardware version 15).
2. Выберите Microsoft Windows 10 (64-bit) в качестве версии ОС (Windows 11 в списке отсутствует).
3. Вручную добавьте vTPM в разделе Customize Hardware.

4. В разделе VM Options установите параметры Encrypted vMotion и Encrypted FT в значение Required (это временная мера для поддержки Windows 11).

5. Завершите мастер создания ВМ.

Помните, что для виртуальных дисков рекомендуется использовать контроллер VMware Paravirtual SCSI (PVSCSI) в целях оптимизации производительности.

Клонирование и шаблоны виртуальных машин с vTPM

• Клонирование ВМ

Если вы удалите или замените устройство vTPM на виртуальной машине с Windows 11, используя функции, такие как Windows BitLocker или Windows Hello, эти функции перестанут работать, и вы можете потерять доступ к операционной системе Windows или данным, если у вас нет соответствующих вариантов восстановления.

При клонировании ВМ с vTPM с помощью vSphere Client устройство и его секреты копируются. Для соблюдения лучших практик используйте новую функцию TPM Provision Policy в vSphere 8, чтобы автоматически заменять vTPM при клонировании.

Политика TPM Provision Policy появилась в последней мажорной версии платформы - vSphere 8. Устройства vTPM могут автоматически заменяться во время операций клонирования или развёртывания. Это позволяет соблюдать лучшие практики, при которых каждая виртуальная машина содержит уникальное устройство TPM, и улучшает поддержку массового развёртывания Windows 11 в больших инсталляциях. Версия vSphere 8.0 также включает расширенную настройку vpxd.clone.tpmProvisionPolicy, которая задаёт поведение по умолчанию для клонирования, при котором устройства vTPM заменяются.

• Шаблоны ВМ

1. На vSphere 8 при развёртывании из шаблона также можно настроить копирование или замену vTPM.
2. На vSphere 7 настройка vTPM выполняется вручную в процессе развёртывания из шаблона.
3. Для шаблонов в Content Library используйте формат VMTX. Формат OVF/OVA не поддерживает vTPM.

Миграция виртуальных машин Windows 11

1. Миграция ВМ с vTPM выполняется с использованием шифрования vMotion.
2. Для миграции между экземплярами vCenter требуется синхронизация Key Provider.
3. Настройте резервное копирование и восстановление Key Derivation Key (KDK) для Native Key Provider. Подробнее об этом тут:

• Back up a vSphere Native Key Provider
• Restore a vSphere Native Key Provider

Использование WinPE для создания шаблонов Windows 11

ВМ с vTPM не поддерживают формат OVF/OVA. Для создания шаблона можно использовать Windows Preinstallation Environment (WinPE):

1. Создайте ВМ без vTPM.
2. Сохраните её как шаблон в формате OVF/OVA.
3. После развёртывания добавьте уникальный vTPM для каждой ВМ.

Известные проблемы

1. Отсутствие опции Windows 11 при создании ВМ (KB 85665).
2. Ошибка добавления vTPM (KB 85974).
3. Проблемы с резервным копированием Native Key Provider через IP (KB 84068).

Сброс устройства TPM в Windows 11

Вы можете очистить ключи, связанные с устройством TPM, непосредственно изнутри Windows 11. Очистка TPM приведет к утрате всех созданных ключей, связанных с этим TPM, а также данных, защищённых этими ключами, таких как виртуальная смарт-карта или PIN-код для входа. При этом существующее устройство vTPM на виртуальной машине сохраняется. Убедитесь, что у вас есть резервная копия и метод восстановления любых данных, защищённых или зашифрованных с использованием TPM. Об этом написано у Microsoft вот тут.

Продолжаем рассказывать о технологии ярусной памяти Memory Tiering, которая появилась в VMware vSphere 8 Update 3 (пока в статусе Tech Preview). Вильям Лам написал об интересной возможности использования одного устройства как для NVMe Tiering, так и для датасторов VMFS на платформе VMware vSphere.

На данный момент включение NVMe Tiering требует выделенного устройства NVMe. Для производственных систем это, вероятно, не проблема, так как важно избежать конкуренции за ресурсы ввода-вывода на одном устройстве NVMe. Однако для среды разработки или домашней лаборатории это может быть проблемой из-за ограниченного количества доступных NVMe-устройств.

Оказывается, можно использовать одно устройство NVMe для NVMe Tiering!

Для владельцев систем малого форм-фактора, таких как ASUS NUC, с ограниченным количеством NVMe-устройств, есть такой вариант: вы можете запустить ESXi с USB-устройства, сохранив возможность использовать локальный VMFS-датастор и NVMe Tiering. Таким образом, у вас даже останется свободный слот или два для vSAN OSA или ESA!

Важно: Это решение не поддерживается официально со стороны VMware. Используйте его на свой страх и риск.

Шаг 1 - Убедитесь, что у вас есть пустое устройство NVMe, так как нельзя использовать устройство с существующими разделами. Для идентификации и получения имени SSD-устройства используйте команду vdq -q.

Шаг 2 – Скачайте скрипт calculateSharedNVMeTeiringAndVMFSPartitions.sh на ваш хост ESXi и укажите значения для трёх необходимых переменных:

• SSD_DEVICE – имя NVMe-устройства, полученное на шаге 1.
• NVME_TIERING_SIZE_IN_GB – объём хранилища (в гигабайтах), который вы хотите выделить для NVMe Tiering.
• VMFS_DATASTORE_NAME – имя VMFS-датастора, который будет создан на NVMe-устройстве.

Убедитесь, что скрипт имеет права на выполнение, выполнив команду:

Затем запустите его, как показано на скриншоте ниже:

Примечание: скрипт только генерирует необходимые команды, но вам нужно будет выполнить их вручную. Сохраните их — это избавит вас от необходимости вручную рассчитывать начальные и конечные сектора хранилища.

Пример выполнения сгенерированных команд для конкретной настройки: есть NVMe-устройство объёмом 1 ТБ (913,15 ГБ), из которого выделяется 256 ГБ для NVMe Tiering, а оставшееся пространство будет использовано для VMFS-датастора.

С помощью клиента ESXi Host Client мы можем увидеть два раздела, которые мы только что создали:

Шаг 3 – Включите функцию NVMe Tiering, если она еще не активирована, выполнив следующую команду ESXCLI:

Шаг 4 – Настройте желаемый процент использования NVMe Tiering (от 25 до 400), исходя из конфигурации вашей физической оперативной памяти (DRAM), выполнив следующую команду:

Шаг 5 – Наконец, перезагрузите хост ESXi, чтобы настройки NVMe Tiering вступили в силу. После перезагрузки ваш хост ESXi будет поддерживать использование одного NVMe-устройства как для NVMe Tiering, так и для локального VMFS-датастора, готового для размещения виртуальных машин.

Вильям Лам написал интересный пост, посвященный конфигурациям для тестовых лабораторий, в которых можно развернуть полнофункциональный стенд на платформе виртуализации VMware Cloud Foundation (VCF) с гипервизором VMware vSphere.

В последнее время Вильям получает множество запросов как изнутри VMware, так и извне, по поводу рекомендаций по оборудованию для создания нового или обновления существующего домашнего лабораторного/тестового окружения с целью развертывания полноценного решения VMware Cloud Foundation (VCF). Обычно он получает не менее шести запросов в неделю по теме VMware Homelabs, но сейчас их количество возросло. Возможно, это связано с недавними распродажами в США на Black Friday и Cyber Monday, а возможно, некоторые уже готовятся к переезду на VCF 9.

В любом случае, он обычно направляет пользователей к своему проекту VMware Community Homelab, основанному на коллективной работе, где участники могут делиться своими списками оборудования (bill of materials, BOM), совокупными затратами на оборудование и решениями VMware, которые они используют в полученной среде.

Проект VMware Community Homelab существует уже несколько лет и помог множеству пользователей. Однако большинство предоставленных конфигураций в основном охватывают лишь часть портфолио VMware, и только небольшое количество из них включает VCF. Более того, некоторые из этих конфигураций устарели на несколько лет.

Внутри компании уже несколько человек поделились более актуальными списками оборудования (BOM) для создания среды, способной запускать последнюю версию VCF 5.x. Также Вильям нашел несколько подобных решений вне VMware. Поэтому он решил, что было бы полезно и своевременно собрать их аппаратные конфигурации, чтобы дать пользователям представление о том, что работает и какие варианты доступны, особенно в преддверии обновления лабораторий к 2025 году.

Нужно также упомянуть несколько ресурсов, которые могут быть полезны при создании вашей новой лаборатории/тестовой среды с VCF:

• Ознакомьтесь с этой статьей VMware KB о выводе из эксплуатации и прекращении поддержки процессоров в выпусках vSphere, чтобы понять, какие процессоры будут поддерживаться в будущем, особенно с учетом следующего крупного релиза vSphere.
• Многие сотрудники используют популярный сайт PC Server and Parts для поиска мощных, но относительно недорогих настольных рабочих станций старых поколений. Это хороший вариант, если вы не хотите тратить деньги на процессоры Intel или AMD последнего поколения.
• Если вы выберете процессор, который больше не поддерживается, убедитесь, что он поддерживает инструкцию XSAVE CPU. Также можно обойти проверку установщика ESXi, используя параметр allowLegacyCPU=TRUE.
• Память часто является первым ресурсом, который исчерпывается, поэтому убедитесь, что у вас есть достаточная емкость NVMe для использования новой функции vSphere NVMe (Memory) Tiering. Это кардинально меняет правила игры, независимо от того, запускаете ли вы нагрузки в лаборатории или будете использовать их в будущем в продакшене.
• Что касается выбора процессоров, Вильям заметил, что всё больше пользователей отдают предпочтение процессорам AMD, а не Intel. Причина — не только стоимость, но и общие возможности (количество ядер, энергопотребление, охлаждение и т. д.). Например, у Raiko (см. ниже для получения дополнительной информации) есть отличная конфигурация, которую многие считают очень экономически выгодной. Многие планируют использовать его BOM для своих VCF-лабораторий.

Вот основные моменты его конфигурации (кликните для увеличения картинки):

• Независимо от того, создаете ли вы лабораторную среду для работы или дома, в конечном счете, дело не только в самом оборудовании (хотя и в нем тоже), а в инвестиции в себя и свою карьеру. Вы получите от этой работы столько, сколько в нее вложите. У всех разные потребности, поэтому универсального решения не существует. Ресурсы проекта VMware Community Homelab Project и конфигурации, представленные ниже, помогут вам понять, что работает, ну а в конечном итоге выбор лучшей конфигурации зависит от ваших требований, бюджета и целей.

Примечание: если вы недавно (в течение последнего года) построили новую лабораторную среду для запуска VCF 5.x или более поздних версий и хотите поделиться своим опытом, отправьте их через VMware Community Homelab Project, перейдя сюда.

Ну и, собственно, таблица наиболее удачных конфигураций:

Компания Veeam, лидирующий на рынке вендор решений для резервного копирования, выпустила обновленную версию продукта Veeam Backup & Replication v12.3.

Давайте посмотрим, что нового:

• Microsoft Entra ID:
  • Ускоренное обнаружение изменений и точечное восстановление данных.
  • Автоматизация процессов резервного копирования для соблюдения требований соответствия.
  • Восстановление на уровне объектов, включая регистрацию приложений.

• Поддержка Microsoft Windows Server 2025 и Windows 11 24H2.
• Расширенные возможности защиты Nutanix AHV.
• Поддержка баз данных MongoDB 8, PostgreSQL 17, Oracle RMAN (23ai), SAP HANA и последних версий Linux и macOS.

• Indicators of Compromise (IoC) Detection: обнаружение инструментов злоумышленников и аномалий файловой системы.
• Veeam Threat Hunter: встроенный механизм обнаружения угроз, основанный на машинном обучении и эвристическом анализе.

Простое развертывание с улучшенной безопасностью, низкими затратами и гибкостью.

Veeam Intelligence: встроенная помощь на базе AI, предоставляющая рекомендации по оптимизации производительности и устранению неполадок.

Оптимизация резервного копирования и восстановления с использованием улучшенных механизмов обработки образов и файлов.

Интеграция с NetApp SnapDiff для ускоренного резервного копирования.

Новые функции в Veeam Agent for Windows, Linux и Mac, включая автоматическое восстановление "на голое железо".

Улучшенные возможности восстановления и управления резервными копиями для баз данных SQL Server, Oracle, MongoDB, PostgreSQL.

Расширенная интеграция с Google Cloud и платформами Red Hat Virtualization (RHV).

Улучшенная миграция репозиториев резервных копий и поддержка шифрования на уровне архива.

Автоматическое создание объектов в S3-хранилищах для повышения производительности.

Повышенная производительность и улучшенная навигация по технической документации.

Поддержка PowerShell и REST API для автоматизации управления резервными копиями.

Скачать последнюю версию решения Veeam Backup & Replication v12.3 можно по этой ссылке.

Последнее независимое исследование, проведенное компанией Principled Technologies, показало, что по сравнению с Red Hat OpenShift Virtualization 4.16.2, платформа VMware vSphere поддерживает на 62% больше транзакций баз данных и сохраняет их стабильную производительность при увеличении количества виртуальных машин. Кроме того, vSphere поддерживает в 1.5 раза больше виртуальных машин на хост, чем OpenShift, без необходимости дополнительной настройки для переподписки памяти (memory overcommitment).

VMware vSphere — это корпоративная платформа виртуализации вычислительных ресурсов, разработанная для предоставления преимуществ облачных технологий в рамках локальных рабочих нагрузок. Она объединяет передовые облачные инфраструктурные технологии с ускорением, основанным на процессорах для обработки данных (DPU) и графических процессорах (GPU), чтобы повысить производительность машин. Сегодня более 300 000 компаний используют vSphere для обеспечения цифровой трансформации. vSphere позволяет ИТ-командам повысить операционную эффективность, ускорить внедрение DevOps-решений и усилить безопасность.

Последнее обновление VMware vSphere 8 Update 3 включает специальную функцию управления памятью для технологии memory overcommitment, которая помогает балансировать производительность виртуальных машин и их плотность. Но как управление памятью в vSphere соотносится с конкурирующими решениями? Компания Principled Technologies провела детальное исследование производительности и плотности виртуальных машин для VMware vSphere 8 Update 3 в сравнении с Red Hat OpenShift Virtualization версии 4.16.2.

Обзор протестированных сценариев

Исследование Principled Technologies началось с тестирования 10 виртуальных машин с установленной СУБД SQL Server c использованием нагрузки TPROC-C для оценки производительности OLTP-транзакций (измеряемой в операциях в минуту, NOPM) для каждой платформы. Начальная конфигурация предполагала memory overcommitment без фактического перераспределения памяти или стрессового использования других ресурсов сервера. Затем плотность виртуальных машин постепенно увеличивалась: сначала до 12 ВМ, создавая сценарий с небольшой переподпиской по памяти, после чего добавлялись ВМ до тех пор, пока производительность платформы не снизилась на 10% или более. Как только платформа показывала значительное ухудшение производительности, тестирование масштабирования для него прекращалось.

Оба сценария использовали один и тот же сервер Dell PowerEdge R650, отличалась только используемая платформа виртуализации.

Ключевые результаты исследования от Principled Technologies

• vSphere 8 обеспечивает лучшую производительность OLTP-транзакций и масштабирование до большего количества виртуальных машин без снижения производительности.

В базовом тесте каждое окружение было настроено с 10 виртуальными машинами по 28 ГБ виртуальной памяти (vRAM) каждая, что составило 280 ГБ выделенной памяти без необходимости переподписки. VMware vSphere 8 Update 3 обеспечила на 27,6% больше NOPM (новых операций в минуту), чем OpenShift, при этих условиях.

На следующем этапе тестирования на обех платформах виртуальное окружение масштабировалось до 12 виртуальных машин, что превысило физическую память сервера и потребовало переподписки. vSphere 8 Update 3 успешно справилась с этим увеличением без дополнительных настроек, обеспечив рост NOPM на 6% относительно базового уровня. Напротив, OpenShift потребовала ручной настройки переподписки памяти, что привело к снижению NOPM на 6,9% относительно базового уровня.

Эти результаты показывают, что vSphere 8 Update 3 не только эффективно поддерживает переподписку памяти на производственном уровне, но и увеличивает плотность виртуальных машин и производительность транзакций с минимальным вмешательством в конфигурацию.

• vSphere 8 достигает более высоких пределов плотности виртуальных машин с минимальным падением производительности

Когда оба решения были доведены до предела их возможностей для определения порога плотности виртуальных машин, была зафиксирована значительная деградация (снижение NOPM более чем на 10%). VMware vSphere 8 Update 3 достигла значительной деградации при 20 виртуальных машинах, показав снижение NOPM на 14,31% по сравнению с конфигурацией из 12 виртуальных машин с небольшой переподпиской памяти. В то же время OpenShift Virtualization 4.16.2 столкнулась с деградацией уже при 13 виртуальных машинах, продемонстрировав снижение NOPM на 23,19% по сравнению с конфигурацией из 12 виртуальных машин. Это указывает на более низкий порог плотности для оптимальной производительности в случае OpenShift.

При запуске 20 виртуальных машин решение vSphere 8 Update 3 достигло пикового уровня загрузки процессора в 94,4%. При 12 виртуальных машинах загрузка процессора у vSphere составила 91,7%, а при 10 виртуальных машинах — 80,1%. В то же время решение OpenShift Virtualization 4.16.2 показало загрузку процессора в 58,3% при 13 виртуальных машинах, 61,5% при 12 виртуальных машинах и 52,1% при 10 виртуальных машинах. Этот тест демонстрирует, что vSphere 8 Update 3 может справляться с более высокой плотностью виртуальных машин, обеспечивая лучшую стабильность производительности при переподписке выделенной памяти по сравнению с OpenShift.

На второй день конференции VMware Explore в Барселоне обсуждались передовые технологии, включая решения VMware Private AI Foundation и их интеграцию с решениями от NVIDIA. В видео ниже ведущие эксперты делятся опытом применения Retrieval Augmented Generation (RAG) и другими ключевыми возможностями Private AI для повышения эффективности работы корпоративных систем и оптимизации использования AI.

1. Что такое VMware Private AI?

   • VMware Private AI — это платформа, которая позволяет использовать возможности искусственного интеллекта, сохраняя конфиденциальность данных.
   • RAG (Retrieval Augmented Generation) — технология, интегрирующая базу данных с частными данными в модели AI, что обеспечивает точные ответы и минимизирует "галлюцинации" модели.
2. Ключевые сценарии использования Private AI:
   • Внутренние чат-боты: помощь сотрудникам, например, операторам колл-центров, в быстром получении ответов с использованием внутренних данных компании.
   • Генерация кода: создание инструментов для разработчиков на основе частных данных, таких как внутренний исходный код.
   • Работа с внутренними базами знаний: быстрый доступ к информации, хранящейся в документации или системах управления знаниями, таких как Confluence.
3. RAG: Что это и как работает?
   • Использует внутренние базы данных (векторные базы данных) для поиска информации, релевантной запросу.
   • Пример: при запросе информация сначала ищется в базе знаний, а затем контекст передается модели AI для создания точного и краткого ответа.
4. Интеграция с NVIDIA:
   • Использование NVIDIA NGC для адаптации моделей под ресурсы, такие как GPU, с возможностью значительного повышения производительности (в 2–8 раз).
   • Поддержка различных уровней точности вычислений (FP32, FP16 и другие) для оптимального баланса скорости и качества.
5. Модельное управление и тестирование:
   • Встроенные инструменты для проверки моделей AI на наличие ошибок, галлюцинаций и других проблем до их использования.
   • Гибкая интеграция любых моделей, включая те, что загружаются из Hugging Face, NVIDIA или создаются внутри компании.
6. Преимущества подхода Private AI:
   • Сохранение конфиденциальности данных в онпремизных средах.
   • Повышение точности работы моделей за счет использования внутренних данных.
   • Улучшение взаимодействия сотрудников с клиентами и внутри команды.

Для кого это видео:

• Системных администраторов, DevOps-инженеров, специалистов по AI.
• Компаний, стремящихся внедрить передовые технологии AI, сохраняя конфиденциальность данных.
• Тех, кто хочет углубить знания в области RAG и Private AI.

Посмотрите это видео, чтобы узнать больше о том, как VMware и NVIDIA трансформируют корпоративные системы с помощью искусственного интеллекта.

На портале технических ресурсов Broadcom появилась полезная статья, посвященная производительности облачных приложений и причинам их земедления в производственной среде.

Часто бывает, что приложение, работающее на физическом сервере, демонстрирует хорошую производительность. Однако после упаковки приложения в образ, тестирования в Docker/Podman и последующей миграции в окружение Kubernetes производительность резко падает. По мере увеличения числа запросов к базе данных, выполняемых приложением, время отклика приложения возрастает.

Эта распространённая ситуация часто вызвана задержками ввода-вывода, связанными с передачей данных. Представьте, что это же приложение снова запускается на физическом сервере, но в следующем сценарии: устройство хранения базы данных создаётся на удалённом хранилище с Network File System (NFS).

Это означает, что необходимо учитывать следующие факторы:

• Количество приложений, обращающихся к конечной точке хранилища (предполагается, что оно быстрое по своему устройству).
  Это будет влиять на общую производительность отклика из-за производительности подсистемы ввода-вывода хранилища.

• Способ, которым приложение извлекает данные из базы данных.
  Кэширует ли оно данные, или просто отправляет очередной запрос? Являются ли запросы небольшими или крупными?

• Задержка, вызванная сетевым доступом к хранилищу, и общая скорость работы хранилища.
  При доступе к сетевому устройству несколько ключевых факторов влияют на скорость передачи данных:

  • Доступная скорость соединения
  • Используемое максимальное время передачи (MTU) / максимальный размер сегмента (MSS)
  • Размер передаваемой полезной нагрузки
  • Настройки TCP окна (скользящее окно)
  • Среднее время задержки при прохождении маршрута (RTT) от точки A до точки B в мс.

В датацентре скорость соединения обычно не является проблемой, поскольку все узлы соединены с пропускной способностью не менее 1 Гбит/с, иногда 10 Гбит/с, и подключены к одному коммутатору. MTU/MSS будет оптимальным для настроенного соединения. Остаются размер передаваемой полезной нагрузки, скользящее окно TCP и среднее RTT. Наибольшее влияние окажут размер полезной нагрузки, задержка соединения и его качество, которые будут влиять на параметры скользящего окна.

Вот пример задержек между узлами в текущей настройке Kubernetes:

При увеличении размера полезной нагрузки пакета в пинге, как только он превышает текущий MTU, время отклика начинает увеличиваться. Например, для node2 размер полезной нагрузки составляет 64k — это экстремальный случай, который наглядно демонстрирует рост задержки.

Учитывая эти три момента (размер передаваемой полезной нагрузки, скользящее окно TCP и среднее RTT), если разработчик создаёт приложение без использования встроенных возможностей кэширования, то запросы к базе данных начнут накапливаться, вызывая нагрузку на ввод-вывод. Такое упущение направляет все запросы через сетевое соединение, что приводит к увеличению времени отклика всего приложения.

На локальном хранилище или в среде с низкой задержкой (как сети, так и хранилища) можно ожидать, что приложение будет работать хорошо. Это типичная ситуация, когда команды разработки тестируют все в локальной среде. Однако при переходе на сетевое хранилище задержка, вызванная сетью, будет влиять на возможный максимальный уровень запросов. При проведении тех же тестов в производственной среде команды, вероятно, обнаружат, что система, способная обрабатывать, скажем, 1000 запросов к базе данных в секунду, теперь справляется только с 50 запросами в секунду. В таком случае стоит обратить внимание на три вероятные причины:

1. Переменные размеры пакетов, средний размер которых превышает настроенный MTU.
2. Сетевая задержка из-за того, что база данных размещена на отдельном узле, вдали от приложения.
3. Уменьшенное скользящее окно, так как все связанные системы подключаются к узлу базы данных. Это создаёт нагрузку на ввод-вывод файловой системы, из-за чего база данных не может обрабатывать запросы достаточно быстро.

Тесты показали, что алгоритм скользящего окна привёл к снижению скорости передачи данных (для справки: это механизм, используемый удалённым хранилищем на основе NFS). При среднем размере полезной нагрузки 4 Кб скорость передачи данных упала с 12 МБ/с на быстром соединении 1 Гбит/с (8 мс задержки) до ~15 Кбит/с, когда задержка соединения достигла 180 мс. Скользящее окно может вынудить каждую передачу данных возвращать пакет подтверждения (ACK) отправителю перед отправкой следующего пакета на соединениях с низкой задержкой.

Эту ситуацию можно протестировать локально с помощью утилиты tc на системе Linux. С её помощью можно вручную задать задержку для каждого устройства. Например, интерфейс можно настроить так, чтобы он отвечал с задержкой в 150 мс.

На Kubernetes, например, вы можете развернуть приложение с фронтендом, сервером приложений и бэкендом базы данных. Если сервер приложений и бэкенд базы данных развернуты на разных узлах, даже если эти узлы быстрые, они будут создавать сетевые задержки для каждого пакета, отправленного с сервера приложений в базу данных и обратно. Эти задержки суммируются и значительно ухудшают производительность!

Ниже приведён реальный пример, показывающий время отклика приложения. База данных развернута на node2.

В этом случае выполнение приложения требует большого количества запросов к базе данных, что значительно влияет на среднее время отклика затронутых компонентов. В данном случае среднее время отклика составляет 3,9 секунды.

Для этого теста функция graph_dyn запрашивает из базы данных 80 тысяч строк данных, где каждая строка содержит метаданные для построения различных точек графика.

Переместив базу данных на ту же машину, где размещена часть приложения, удалось снизить среднее время отклика до 0,998 секунды!

Это значительное улучшение производительности было достигнуто за счёт сокращения задержек сетевых запросов (round trip), то есть перемещения контейнера базы данных на тот же узел.

Ещё одним распространённым фактором, влияющим на производительность Kubernetes, являются ESXi-среды, где узлы кластера имеют избыточную нагрузку на ввод-вывод сети, а узлы Kubernetes развёрнуты в виде виртуальных машин. Узел Kubernetes не может увидеть, что CPU, память, ввод-вывод диска и/или подключённое удалённое хранилище уже находятся под нагрузкой. В результате пользователи сталкиваются с ухудшением времени отклика приложений.

Как оптимизировать производительность приложения

1. Учтите кэширование в дизайне приложения.
   Убедитесь, что приложение учитывает кэширование (общих запросов, запросов к базе данных и так далее) и не выполняет лишних запросов.

2. Отключите переподписку ресурсов (oversubscription) в средах ESXi.
   Если Kubernetes/OpenShift работают поверх ESXi, убедитесь, что переподписка ресурсов отключена для всех доступных CPU и памяти. Учтите, что даже небольшие задержки могут быстро накопиться и привести к эластичному поведению времени отклика приложения. Кроме того, если хост ESXi уже находится под нагрузкой, запущенные на нём образы не будут осведомлены об этом, и оркестратор Kubernetes может развернуть дополнительные поды на этом узле, считая ресурсы (CPU, память, хранилище) всё ещё доступными. Поэтому, если вы используете Kubernetes/OpenShift, а у вас есть возможность запустить их на физическом сервере, сделайте это! Вы получите прямую и полную видимость ресурсов хоста.

3. Минимизируйте сетевые задержки ввода-вывода в Kubernetes.
   Сократите сетевые задержки ввода-вывода при развёртывании подов. Упакуйте контейнеры в один под, чтобы они развертывались на одном узле. Это значительно снизит сетевые задержки ввода-вывода между сервером приложений и базой данных.

4. Размещайте контейнеры с высокими требованиями к базе данных на узлах с быстрым хранилищем.
   Развёртывайте контейнеры, которым требуется быстрый доступ к базе данных, на узлах с быстрым хранилищем. Учитывайте требования к высокой доступности и балансировке нагрузки. Если хранилище NFS недостаточно быстрое, рассмотрите возможность создания PV (Persistent Volume) на определённом узле с локальным RAID 10 диском. Учтите, что в этом случае резервирование придётся настраивать вручную, так как оркестратор Kubernetes не сможет управлять этим при отказе оборудования конкретного узла.

Как мониторить задержки между компонентами

Для Kubernetes, OpenShift и Docker (Swarm) можно использовать Universal Monitoring Agent (UMA), входящий в решения AIOps and Observability от Broadcom, для мониторинга взаимодействия всего окружения. Этот агент способен извлекать все релевантные метрики кластера. Если UMA обнаруживает поддерживаемую технологию, такую как Java, .Net, PHP или Node.js, он автоматически внедряет пробу (probe) и предоставляет детализированную информацию о выполнении приложения по запросу. Эти данные включают запросы ввода-вывода (I/O) от компонента к базе данных, удалённые вызовы и другие внутренние метрики приложения.

Если приложение работает некорректно, встроенное обнаружение аномалий UMA запускает трассировку транзакций (это не требует дополнительной настройки). UMA собирает подробные метрики с агентов, связанных с компонентами, по пути выполнения конкретного приложения. Эти возможности позволяют получить детализированное представление выполнения приложения вплоть до строки кода, вызывающей замедление. Администраторы могут настроить полный сквозной мониторинг, который предоставляет детали выполнения, включая производительность фронтенда (браузера).

Ниже приведен пример сбора полных сквозных метрик, чтобы команда администраторов могла проанализировать, что пошло не так, и при необходимости принять корректирующие меры:

User front-end => Web-Server front-end => app-server => databases | remote services

Одним из преимуществ этого решения для мониторинга является то, что оно показывает среднее время выполнения компонентов внутри кластера. Со временем решение может начать считать плохие средние значения нормой в среде ESXi с избыточной загрузкой. Тем не менее, оператор может оценить реальные значения и сравнить их с показателями других приложений, работающих на том же узле.

Компания VMware недавно выпустила интересное видео в рамках серии Extreme Performance, где рассматривается, как технологии Memory Tiering могут оптимизировать серверную инфраструктуру, улучшить консолидацию серверов и снизить общую стоимость владения (TCO). Ведущие эксперты, работающие в сфере производительности платформ VMware, делятся новейшими разработками и результатами тестов, которые помогут сделать работу администраторов с серверами более эффективной.

Основные моменты видео:

1. Что такое Memory Tiering? Memory Tiering — это технология, реализованная в ядре ESXi, которая прозрачно для приложений и гостевых ОС разделяет память на два уровня:

   • Tier 1: Быстрая память DRAM.
   • Tier 2: Бюджетные и емкие устройства памяти, такие как NVMe SSD и CXL.
2. Преимущества Memory Tiering:
   • Увеличение доступной памяти за счет использования NVMe в качестве памяти второго уровня.
   • Снижение затрат на память до 50%.
   • Исключение таких проблем, как ballooning и случайный обмен страницами.
3. Реальные результаты:
   • Удвоение плотности виртуальных машин (VMs): на одной хост-машине можно разместить вдвое больше ВМ без заметной потери производительности (<3%).
   • Оптимизация работы баз данных: для SQL Server и Oracle наблюдалось почти линейное масштабирование с минимальными потерями производительности.
   • Стабильный пользовательский опыт (VDI): эталонный тест Login VSI показал, что даже при удвоении числа ВМ пользовательский опыт остается на высоком уровне.
4. Ключевые метрики и рекомендации:
   • Active memory: один из основных параметров для мониторинга. Оптимальный уровень — около 50% от объема Tier 1 (DRAM).
   • Использование NVMe: рекомендации по чтению и записи (до 200 мс latency для чтения и 500 мс для записи).
5. Практические примеры и кейсы:
   • Клиенты из финансового и медицинского секторов, такие как SS&C Cloud, уже успешно применяют Memory Tiering, чтобы уменьшить затраты на серверы и улучшить их производительность.
6. Советы по настройке и мониторингу:
   • Как отслеживать активность NVMe-устройств и состояние памяти через vCenter.
   • Какие показатели важны для анализа производительности.

Кому будет полезно:

• Системным администраторам, DevOps-инженерам и специалистам по виртуализации.
• Организациям, которые стремятся сократить затраты на ИТ-инфраструктуру и повысить плотность виртуализации.
• Любителям передовых технологий, которые хотят понять, как современные подходы меняют управление памятью в дата-центрах.

Memory Tiering — это прорывная технология, которая уже сегодня позволяет добиться больших результатов в консолидации серверов. Узнайте, как её применить в вашем окружении, и станьте частью следующего поколения производительности серверов.

Дункан Эппинг продолжает рассказывать о новых возможностях платформы VMware Cloud Foundation 9, которая была представлена на прошедшей конференции VMware Explore 2024.

На этот раз Дункан рассказал о работе функции Federated Storage View для платформы VMware vSAN, а также для других традиционных систем хранения данных. Это представление позволит получить визуальную информацию о емкостях и производительности хранилищ, а также наглядно отобразит конфигурацию растянутого кластера (stretched cluster).

Поскольку это визуальный инструмент, Дункан записал обзорное видео, из которого вы сможете понять, как это работает:

На конференции Explore в Барселоне было сделано несколько объявлений и показаны элементы дорожной карты, которые не были представлены ранее в Лас-Вегасе. Так как сессии в Барселоне не записывались, Дункан Эппинг поделился функциями, о которых он говорил на Explore, и которые в настоящее время планируются для платформы VCF 9. Обратите внимание, что неизвестно, когда эти возможности станут общедоступными, и всегда существует вероятность, что они могут не выйти вообще.

Дункан сделал видео с демонстрацией обсуждаемых фич, чтобы вы могли их увидеть уже сегодня:

Для тех, кто не смотрит видео, ниже кратко описана функциональность, над которой VMware работает для VCF 9. Публичное объявление об этом пока не сделано, поэтому большого количества деталей не будет.

vSAN Automated Site Maintenance

В среде с растянутым кластером vSAN, когда вы хотите выполнить обслуживание узла, на сегодняшний день вам нужно переводить каждый хост в режим обслуживания по одному. Это не только административная/операционная нагрузка, но и увеличивает риск случайного перевода в режим обслуживания неправильных хостов. Более того, из-за последовательного подхода данные, хранящиеся на хосте 1 в сайте A, могут отличаться от данных на хосте 2 в сайте A, что создает несогласованность данных в пределах сайта.

Обычно это не является проблемой, так как система синхронизируется после завершения обслуживания, но если в это время выйдет из строя другой сайт с данными, существующий (несогласованный) набор данных не сможет быть использован для восстановления. Функция Site Maintenance не только упрощает перевод всего сайта в режим обслуживания, но и устраняет риск несогласованности данных, так как vSAN координирует процесс обслуживания и гарантирует согласованность данных в пределах сайта.

vSAN Site Takeover

Одной из функций, которой многим не хватало долгое время, была возможность сохранить работоспособность сайта в случае, если два из трех сайтов одновременно выходят из строя. Здесь на помощь приходит функция Site Takeover. Если вы оказались в ситуации, когда одновременно выходят из строя как Witness Site, так и сайт с данными, вы все равно хотите иметь возможность восстановить работу. Особенно учитывая, что на втором сайте, скорее всего, имеются здоровые объекты для каждой ВМ. Функция vSAN Site Takeover поможет в этом. Она позволит вручную (через интерфейс или скрипт) указать vSAN, что, несмотря на потерю кворума, локальный набор RAID для каждой затронутой ВМ должен быть снова доступен. После этого, конечно, vSphere HA даст хостам команду включить эти ВМ.

На конференции VMware Explore 2024 в Барселоне компания Broadcom представила революционную сетевую архитектуру VeloRAIN, предназначенную для поддержки и оптимизации рабочих нагрузок, связанных с искусственным интеллектом (AI), в рамках больших предприятий. VeloRAIN (RAIN - это Robust AI Networking) создана для улучшения производительности и безопасности AI-нагрузок в распределенных средах, что делает её важным инструментом для современных предприятий, сталкивающихся с растущими потребностями в передаче данных и выполнении AI-задач.

Основные Преимущества VeloRAIN

• Выявление AI-приложений с помощью AI и машинного обучения (ML)

Одной из ключевых особенностей VeloRAIN является способность обнаруживать зашифрованный трафик приложений, который ранее было невозможно анализировать стандартными решениями для оптимизации сети. Это дает компаниям возможность более точно определять и выделять приоритеты для AI-приложений, что, в свою очередь, позволяет повысить качество обслуживания (QoS) и улучшить пользовательский опыт.

• Повышение эффективности сети и оптимизация трафика

VeloRAIN предлагает инновационные методы оценки качества каналов связи, которые помогают улучшить обслуживание пользователей при работе с беспроводными каналами, включая 5G и спутниковые соединения. Это позволяет достичь качества, сравнимого с проводной связью, даже при изменяющихся условиях сети. Кроме того, архитектура ускоряет настройку сетей в удаленных офисах или филиалах, делая запуск инфраструктуры более быстрым и менее трудоемким.

• Динамическая система управления приоритетами на основе AI

Новая динамическая платформа управления политиками автоматизирует присвоение приоритетов для приложений, что упрощает управление сетью. С помощью функции Dynamic Application-Based Slicing (DABS) платформа VeloRAIN обеспечивает высокое качество обслуживания для каждого приложения, даже если сети, по которым передаются данные, не поддерживают послойную сегментацию. DABS также использует профили пользователей, чтобы предоставлять приоритетный трафик ключевым сотрудникам, улучшая их опыт и общую производительность сети.

• Автоматизация и мониторинг сети с использованием AI

VeloRAIN позволяет компаниям получить глубокую видимость работы сети, автоматизировать процессы приоритезации и мониторинга, а также сократить вмешательство со стороны IT-специалистов. Это особенно важно для AI-нагрузок, которые являются автономными и требуют оркестрации, а не ручного администрирования. Используя VeloRAIN, предприятия могут более эффективно и оперативно настраивать свои сети под потребности бизнес-нагрузок, что улучшает адаптивность к изменениям в рабочем процессе и инфраструктуре.

Стратегическая Значимость VeloRAIN для современного бизнеса

VeloRAIN представляет собой значительный шаг вперед в управлении распределенными рабочими нагрузками AI, так как позволяет предприятиям быстро адаптироваться к изменениям и обеспечивать безопасность и производительность своих AI-нагрузок. С помощью этой архитектуры компании смогут не только улучшить качество взаимодействия с клиентами, но и оптимизировать расходы, так как система автономно распределяет приоритеты и адаптируется под изменения в сети.

Цель Broadcom в развитии сетевой инфраструктуры на базе AI

Как отметил Санжай Аппал, вице-президент и генеральный директор подразделения VeloCloud компании Broadcom, VeloRAIN станет основой инноваций компании в AI-сетях, предоставляя компаниям инструменты для оптимизации их AI-нагрузок. Broadcom планирует активно развивать свою экосистему партнеров, чтобы предоставить компаниям инфраструктуру нового поколения для поддержки AI и облачных рабочих нагрузок в будущем.

Прочие анонсы VeloCloud

VeloCloud Edge 4100 и 5100: высокопроизводительные устройства для крупных предприятий

Broadcom представила устройства VeloCloud Edge 4100 и 5100, которые обеспечивают повышенную пропускную способность и масштабируемость. Устройство Edge 4100 поддерживает до 30 Гбит/с и до 12 000 туннелей, а Edge 5100 — до 100 Гбит/с и до 20 000 туннелей. Эти решения упрощают сетевую архитектуру и обеспечивают высокую надежность для AI и других рабочих нагрузок.

Titan: Новая партнерская программа для поддержки MSP

Программа Titan предлагает партнерам Managed Service Providers (MSP) эксклюзивные преимущества, такие как стабильный рост бизнеса, доступ к передовым технологиям, новую модель лицензирования и улучшенные возможности по предоставлению управляемых услуг для клиентов.

Особенности новой программы:

• Вознаграждение на основе показателей, включая совместную разработку решений, признание на рынке и стабильный и предсказуемый рост бизнеса.
• Эксклюзивный доступ к инновационным технологиям и каналам выхода на рынок.
• Новая модель лицензирования, обеспечивающая переносимость лицензий, простоту управления и стабильность цен.
• Программа создания услуг, ориентированная на ключевые ценностные драйверы, вертикальное выравнивание и более высокие маржинальные показатели.
• Новое предложение «White label», позволяющее партнерам высшего уровня расширять базу VeloCloud через региональных и специализированных партнеров канала.

В то время, как организации по всему миру стремятся преобразовать свою инфраструктуру, чтобы соответствовать требованиям цифровой эпохи, гиперконвергентное хранилище стало ключевым инструментом для модернизации ИТ. Решение VMware vSAN находится на переднем плане этой революции, предлагая гибкое, масштабируемое и экономически эффективное решение для управления критически важными рабочими нагрузками.

Однако, когда ИТ-служба принимает решение о внедрении новой технологии, такой как гиперконвергентное хранилище, первый шаг может казаться сложным. Есть очевидные моменты для начала, такие как обновление инфраструктуры или новое развертывание ИТ в периферийной локации. Что касается рабочих нагрузок, то кривая внедрения — какие нагрузки выбрать для старта и как продвигаться дальше — может представлять собой некоторую загадку.

VMware недавно заказала исследование Key Workloads and Use Cases for Virtualized Storage у компании Enterprise Strategy Group, чтобы изучить роль гиперконвергентного хранилища, его преимущества и ключевые случаи применения, где оно оказывает значительное влияние. Рекомендации основаны на опросах сотен пользователей гиперконвергентных хранилищ, а также на тысячах реальных внедрений.

Почему хранилище является проблемой

В стремительно меняющемся цифровом мире управление хранилищем становится сложной задачей. Объемы данных растут экспоненциально из-за таких факторов, как искусственный интеллект, интернет вещей (IoT) и облачные приложения. Сложность и фрагментация хранилищ также увеличиваются, поскольку данные распределены между локальными, облачными и периферийными локациями. Традиционные архитектуры хранилищ на основе трехуровневых систем становятся дорогостоящими, трудными для масштабирования и требуют специальных навыков. Это создает острую необходимость в новом подходе, который упрощает хранение данных, одновременно удовлетворяя растущие потребности современных приложений.

Роль гиперконвергентного хранилища

VMware vSAN устраняет ограничения традиционного хранилища с помощью гиперконвергентного подхода, который объединяет ресурсы хранилища нескольких серверов в единую общую базу данных. Это упрощает управление, улучшает производительность и обеспечивает постепенное масштабирование. В отличие от традиционного хранилища, которое является жестким и дорогим, гиперконвергентное хранилище предлагает гибкую модель, позволяющую организациям масштабироваться вверх или вниз по мере необходимости и работать на серверах промышленного стандарта, снижая капитальные затраты. Гиперконвергентное хранилище позволяет организациям использовать единую программно-определяемую инфраструктуру и единый операционный подход для основного датацентра, периферийной инфраструктуры и публичного облака, что значительно упрощает управление в крупных масштабах. VMware имеет обширный список совместимого оборудования, сертифицированного для работы vSAN как в периферийных системах, так и в основных датацентрах.

Кроме того, vSAN ускоряет рутинные операции с хранилищем, такие как предоставление хранилища за минуты, а не за часы или дни, что делает его идеальным решением для быстро меняющихся условий. Тесная интеграция с облачной инфраструктурой VMware позволяет без проблем управлять как виртуальными машинами, так и контейнерами, что делает его универсальным решением для частных и гибридных облачных сред.

Ключевые рабочие нагрузки для гиперконвергентного хранилища

VMware vSAN подходит для различных сценариев использования, демонстрируя в них свою гибкость и масштабируемость:

1. Виртуальная инфраструктура рабочих столов (VDI): с увеличением числа удаленных сотрудников виртуальные рабочие столы стали критически важными. Однако VDI требует высокой производительности, линейного масштабирования и технологий для сокращения объема данных, чтобы оптимизировать затраты на хранение. vSAN решает эту задачу, предлагая масштабируемое решение. Его архитектура поддерживает высокую производительность и различные технологии сокращения данных для минимизации требований к объему хранения.

2. Бизнес-критичные приложения: для требовательных приложений баз данных, таких как Oracle, SQL Server и SAP HANA, vSAN обеспечивает высокую производительность и масштабируемость. Архитектура vSAN Express Storage Architecture предоставляет высокую производительность и устойчивость, даже с использованием кодирования ошибок RAID 5/6 для эффективности. vSAN также позволяет независимо масштабировать вычислительные ресурсы и ресурсы хранения, что полезно для рабочих нагрузок OTLP, которые часто растут быстрее по объему хранения, чем по вычислительным требованиям.

3. «Мейнстримные» рабочие нагрузки: веб-серверы, аварийное восстановление и защита данных. Это зрелые и широко используемые приложения, для которых требуется простое в управлении и недорогое хранилище. vSAN упрощает работу с этим хранилищем для разных рабочих нагрузок за счет управления на основе политик и снижает затраты, используя серверы промышленного стандарта для достижения необходимой производительности. Он также упрощает аварийное восстановление, позволяя реплицировать данные между сайтами без дорогостоящего специального оборудования.

4. Рабочие нагрузки на периферии (edge workloads): гиперконвергентные решения для хранилищ обеспечивают масштабируемость, гибкость и повышенную производительность на периферии с меньшими затратами, в компактном формате и, что особенно важно, в упрощенном форм-факторе серверов. Ключевые возможности vSAN включают:

• возможность экономного масштабирования
• поддержку нативного файлового и блочного хранения для уменьшения физического объема
• высокую производительность благодаря поддержке NVMe-based TLC NAND flash для приложений с высокой чувствительностью к задержкам
• централизованное управление всеми удаленными сайтами из одного инструмента

5. Облачные (cloud-native) рабочие нагрузки: гиперконвергентные решения для хранилищ также являются идеальным подходом, поскольку они поддерживают облачные хранилища и автоматизируют выделение хранилища для контейнерных рабочих нагрузок, что позволяет разработчикам получать доступ к необходимому хранилищу по мере необходимости, одновременно позволяя ИТ-администраторам управлять хранилищем как для контейнеров, так и для виртуальных машин на одной платформе.

Заключение

VMware vSAN — это не просто решение для хранения, это краеугольный камень ИТ-модернизации. Благодаря использованию виртуализации vSAN позволяет организациям создать гибкую, масштабируемую и эффективную инфраструктуру хранения, способную справиться с текущими и будущими нагрузками. Независимо от того, хотите ли вы оптимизировать рабочие столы VDI, улучшить производительность баз данных или модернизировать стратегию аварийного восстановления, VMware vSAN предоставляет комплексное решение для удовлетворения потребностей пользователей.

Вильям Лам написал наиполезнейшую статью о сбросе/восстановлении пароля консоли сервера VMware ESXi 8 и 7 в составе платформы виртуализации VMware vSphere.

Общее руководство и самый быстрый способ восстановления пароля root для хоста ESXi, если вы забыли или потеряли его, заключается в сбросе с помощью профилей хостов vSphere, если он управлялся сервером vCenter, или просто переустановке ESXi, что позволит сохранить существующие тома VMFS вместе с виртуальными машинами, которые могут на них находиться.

Ранее также было возможно сбросить пароль root ESXi, загрузив систему в Linux и вручную обновив файл /etc/shadow, что похоже на то, как можно сбросить пароль в системе на базе Linux. В сети можно найти множество статей в блогах, описывающих этот процесс. Однако с появлением ESXi Configuration Store данный метод больше не работает для современных версий ESXi, начиная с ESXi 7.0 Update 1 и выше.

Тем не менее, эта тема все еще часто поднимается, особенно в контексте администраторов, которые начинают работать в новой компании, где пароль root ESXi не был должным образом задокументирован, или когда администратору поручено поддерживать набор отдельных ESXi хостов без владельцев. Независимо от сценария, хотя переустановка является самым быстрым способом восстановления, конечно, было бы неплохо сохранить исходную конфигурацию, особенно если нет документации.

Хотя в сети было опубликовано множество фрагментов информации (здесь, здесь и здесь), включая информацию от самого Вильяма, было бы полезно выяснить по шагам актуальный процесс восстановления ESXi 7.x или 8.x хоста без необходимости его переустановки.

Предварительные требования:

• Доступ к физическому носителю, на который установлен ESXi (USB или HDD/SSD)
• Виртуальная машина Linux (Ubuntu или Photon OS)
• Виртуальная машина с вложенным ESXi

Для демонстрации описанного ниже процесса восстановления Вильям установил ESXi 8.0 Update 3c на USB-устройство с базовой конфигурацией (имя хоста, сеть, SSH MOTD), чтобы убедиться в возможности восстановления системы. Затем он изменил пароль root на что-то полностью случайное и удалил этот пароль, чтобы нельзя было войти в систему. Хост ESXi, на котором он "забыл" пароль, будет называться физическим хостом ESXi, а вложенная виртуальная машина с ESXi, которая будет помогать в восстановлении, будет называться вложенным хостом (Nested ESXi).

Шаг 1 — Разверните вложенную виртуальную машину с ESXi (скачать с сайта VMware Flings), версия которой должна соответствовать версии вашего физического хоста ESXi, который вы хотите восстановить.

Шаг 2 — Скопируйте файл state.tgz с физического хоста ESXi, который вы хотите восстановить. Обязательно сделайте резервную копию на случай, если допустите ошибку.

• Если ваш хост ESXi установлен на USB, отключите USB-устройство, подключите его к настольной системе и скопируйте файл с тома BOOTBANK1.
• Если ваш хост ESXi установлен на HDD/SSD, вам нужно будет загрузить физическую систему с помощью Linux LiveCD (Ubuntu или Knoppix) и смонтировать раздел 5 для доступа к файлу state.tgz.

Шаг 3 — Скопируйте файл state.tgz с вашего физического хоста ESXi на вложенный хост ESXi и поместите его в /tmp/state.tgz, затем выполните следующую команду для извлечения содержимого файла:

tar -zxvf state.tgz
rm -f state.tgz

Шаг 4 — Войдите на ваш вложенный хост ESXi и выполните следующие команды для извлечения его файла state.tgz, который будет помещен в каталог /tmp/a. Затем мы используем утилиту crypto-util для расшифровки файла local.tgz.ve вложенного хоста ESXi, чтобы получить файл local.tgz, и затем просто удаляем зашифрованный файл вместе с файлом encryption.info вложенного хоста ESXi. После этого мы заменим их файлом encryption.info с нашего физического хоста ESXi и создадим модифицированную версию state.tgz, которая будет загружаться в нашей вложенной виртуальной машине ESXi. Мы используем это для расшифровки исходного файла state.tgz с нашего физического хоста ESXi.

mkdir /tmp/a
cd /tmp/a
tar xzf /bootbank/state.tgz
crypto-util envelope extract --aad ESXConfiguration local.tgz.ve local.tgz
rm -f local.tgz.ve encryption.info
cp /tmp/encryption.info /tmp/a/encryption.info
tar -cvf /tmp/state-mod.tgz encryption.info local.tgz

После успешного выполнения последней команды, нам нужно скопировать файл /tmp/state-mod.tgz на ваш рабочий стол, а затем выключить вложенную виртуальную машину ESXi.

Шаг 5 — Смонтируйте первый VMDK диск из вашей вложенной виртуальной машины ESXi на вашу виртуальную машину с Linux. В данном случае Вильм использует Photon OS, который также управляет и DNS-инфраструктурой.

Шаг 6 — Убедитесь, что VMDK вашей вложенной виртуальной машины ESXi виден в вашей системе Linux, выполнив следующую команду. Мы должны увидеть два раздела bootbank (5 и 6), как показано на скриншоте ниже:

fdisk -l

Шаг 7 — Перенесите файл state-mod.tgz, созданный на Шаге 4, на вашу виртуальную машину с Linux, затем смонтируйте оба раздела bootbank и замените файл state.tgz на нашу модифицированную версию.

mount /dev/sdb5 /mnt
cp ~/state-mod.tgz /mnt/state.tgz -f
chmod 755 /mnt/state.tgz
umount /mnt

mount /dev/sdb6 /mnt
cp ~/state-mod.tgz /mnt/state.tgz -f
chmod 755 /mnt/state.tgz
umount /mnt

Примечание: Этот шаг необходим, потому что, если вы просто скопируете модифицированный файл state.tgz напрямую на USB-устройство физического хоста ESXi, вы обнаружите, что система восстановит оригинальный файл state.tgz, даже если на обоих разделах содержится модифицированная версия.

Шаг 8 — Сделайте remove (не удаляйте) VMDK файл вложенной виртуальной машины ESXi с виртуальной машины Linux, затем включите вложенную виртуальную машину ESXi.

После успешной загрузки вложенной виртуальной машины ESXi, она теперь работает с оригинальным файлом encryption.info с нашего физического хоста ESXi, что позволит нам восстановить исходный файл state.tgz.

Шаг 9 — Скопируйте исходный файл state.tgz, созданный на Шаге 2, во вложенную виртуальную машину ESXi, поместите его в каталог /tmp/state.tgz и выполните следующую команду, которая теперь позволит нам расшифровать файл state.tgz с физического хоста ESXi, как показано на скриншоте ниже!

cd /tmp
tar -zxvf state.tgz
rm -f state.tgz
crypto-util envelope extract --aad ESXConfiguration local.tgz.ve local.tgz
rm -f local.tgz.ve

Шаг 10 — После расшифровки исходного файла state.tgz у нас должен появиться файл local.tgz, который мы извлечем локально в каталоге /tmp, выполнив следующую команду:

Следующие три каталога: .ssh, etc/ и var/ будут размещены в /tmp, а /tmp/var/lib/vmware/configstore/backup/current-store-1 — это хранилище конфигурации ESXi для физического хоста ESXi, которое нам нужно обновить и заменить оригинальный хеш пароля root на желаемый, чтобы мы могли войти в систему.

Для непосредственного изменения хранилища конфигурации ESXi нам необходимо использовать утилиту sqlite3, так как файл хранится в виде базы данных sqlite3. Мы можем выполнить следующую команду на вложенной виртуальной машине ESXi, чтобы проверить текущий хеш пароля root:

/usr/lib/vmware/sqlite/bin/sqlite3 /tmp/var/lib/vmware/configstore/backup/current-store-1  "select * from config where Component='esx' and ConfigGroup = 'authentication' and Name = 'user_accounts' and Identifier = 'root'"

Шаг 11 — Вам потребуется новый хеш пароля в формате SHA512, где вы знаете сам пароль, после чего выполните следующую команду, заменив хеш.

/usr/lib/vmware/sqlite/bin/sqlite3 /tmp/var/lib/vmware/configstore/backup/current-store-1  "update config set UserValue='{\"name\":\"root\",\"password_hash\":\"\$6\$s6ic82Ik\$ER28x38x.1umtnQ99Hx9z0ZBOHBEuPYneedI1ekK2cwe/jIpjDcBNUHWHw0LwuRYJWhL3L2ORX3I5wFxKmyki1\",\"description\":\"Administrator\"}' where Component='esx' and ConfigGroup = 'authentication' and Name = 'user_accounts' and Identifier = 'root'"

Примечание: Вам нужно правильно экранировать любые специальные символы, например, как в приведенном выше примере, где хеш пароля содержит символ "$". Чтобы убедиться, что замена хеша выполнена правильно, вы можете выполнить вышеуказанную команду запроса, чтобы убедиться, что вывод соответствует желаемому хешу пароля, как показано на скриншоте ниже.

Шаг 12 — Теперь, когда мы обновили хранилище конфигурации ESXi с нашим желаемым паролем root, нам нужно заново создать файл state.tgz, который будет содержать наши изменения, выполнив следующие команды:

rm -f local.tgz 
tar -cvf /tmp/local.tgz .ssh/ etc/ var/ 
tar -cvf /tmp/state-recover.tgz encryption.info local.tgz

Скопируйте файл /tmp/state-recover.tgz с вложенной виртуальной машины ESXi на вашу виртуальную машину с Linux, которая затем будет использоваться для монтирования носителя физического хоста ESXi, чтобы заменить файл state.tgz на нашу восстановленную версию.

Шаг 13 — Смонтируйте носитель физического хоста ESXi на вашу виртуальную машину с Linux. Поскольку физический хост ESXi установлен на USB, можно просто подключить USB-устройство напрямую к виртуальной машине с Linux.

Снова мы можем убедиться, что виртуальная машина с Linux видит носитель с установленным физическим хостом ESXi, выполнив команду fdisk -l, и мы должны увидеть два раздела bootbank (5 и 6), как показано на скриншоте ниже.

Шаг 14 — Теперь нам просто нужно смонтировать раздел bootbank и заменить оригинальный файл state.tgz на нашу модифицированную версию (state-recover.tgz).

mount /dev/sdb5 /mnt 
cp ~/state-recover.tgz /mnt/state.tgz 
chmod 755 /mnt/state.tgz 
umount /mnt

Примечание: Поскольку физический хост ESXi был только что установлен, на втором разделе bootbank не было ничего для замены, но если вы найдете файл state.tgz, его также следует заменить, используя ту же команду, но указав другой номер раздела.

Шаг 15 — Последний шаг: размонтируйте носитель физического хоста ESXi с виртуальной машины Linux, затем включите ваш физический хост ESXi, и теперь вы сможете войти в систему, используя обновленный пароль root!

Интересную статью написал Tom Fojta в своем блоге, касающуюся возможного повреждения данных на платформе VMware vSAN 8.0 (включая пакеты обновлений Update 1 и 2). Согласно статье базы знаний KB 367589, такое повреждение может случиться, если в вашей виртуальной машине некоторые приложения используют набор инструкций AVX-512.

Пока известно, что эти инструкции используются СУБД IBM Db2 и SAP HANA (однако и другие приложения могут их потенциально использовать).

Чтобы проверить, есть ли поддержка AVX-512 у вашего процессора, нужно выполнить следующую команду:

cat /proc/cpuinfo |grep avx512

Вывод команды будет примерно таким:

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 avx2 smep bmi2 invpcid avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xsaves arat pku md_clear flush_l1d arch_capabilities

Жирным тут отмечены слова, свидетельствующие о том, что поддержка этого набора инструкций есть.

Для того, чтобы обнаружить эту поддержку в гостевой ОС Windows, можно запустить утилиту HWiNFO.

Чтобы воспроизвести проблему, можно просто запустить SSH для передачи данных, так как библиотека openssl может использовать инструкции AVX-512:

$ dd if=/dev/zero bs=1M count=1024 | sha256sum -  > sha256sums.zero # one time checksum generation
$ ( while true; rm -f /tmp/zero.$$.img ; do ssh root@localhost "dd if=/dev/zero iflag=fullblock bs=1M count=1024 status=progress" | dd iflag=fullblock bs=1M status=none of=/tmp/zero.$$.img && sha256sum - < /tmp/zero.$$.img | diff -u sha256sums.zero - || exit 1; done )

В итоге проверка контрльной суммы завершится неудачно:

...
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.11915 s, 507 MB/s
1013972992 bytes (1.0 GB, 967 MiB) copied, 2 s, 507 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.09118 s, 513 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2 s, 532 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.01729 s, 532 MB/s
--- sha256sums.zero     2024-10-21 10:44:48.142238490 +0000
+++ -   2024-10-21 10:54:17.289072688 +0000
@@ -1 +1 @@
-49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  -
+4e841c1d34a2a051fab082d10a8105cd34e10c95ee74ce20d280a7c022eaaa53  -

Чтобы решить проблему на уровне процессора (виртуальной машины), нужно отмаскировать некоторые флаги в наборе инструкций CPU. Вы также можете решить проблему и на уровне приложений (для этого обратитесь к KB, указанной выше).

Итак, нужно добавить в Advanced Configuration Parameters виртуальной машины следующие строчки для проблемных инструкций AVX-512:

featMask.vm.cpuid.AVX512F = “Max:0”
featMask.vm.cpuid.AVX512FP16 = “Max:0“

Сделать это можно и через интерфейс vSphere Client или Cloud Director - там нужно создать политику Compute Policy для виртуальных машин (в интерфейсе она называется VM Sizing Policy) с расширенными параметрами:

Дункан Эппинг написал несколько статей о защите данных VMware vSAN, и в последнем посте был представлен хороший демонстрационный пример vSAN Data Protection. В комментариях к оригинальному посту Дункана был задан очень хороший вопрос, касающийся растянутых кластеров vSAN. В основном, он был о том, распространяются ли снапшоты на разные локации. Это отличный вопрос, так как есть несколько моментов, которые, вероятно, стоит прояснить еще раз.

vSAN Data Protection основывается на возможности создания снимков (snapshots), которая была введена с vSAN ESA. Эта функция в ESA значительно отличается от того, как это было реализовано в vSAN OSA или VMFS. В vSAN OSA и VMFS при создании снимка создается новый объект (в vSAN) или файл (в файловой системе VMFS). С vSAN ESA это больше не так, так как теперь не создаются дополнительные файлы или объекты, а вместо этого создается копия структуры метаданных. Именно поэтому снапшоты на vSAN ESA работают гораздо лучше, чем для vSAN OSA или VMFS, так как больше не нужно проходить через множество файлов или объектов для чтения данных. Теперь просто используется тот же объект и задействуется структура метаданных для отслеживания изменений.

В vSAN объекты (и их компоненты) размещаются по всему кластеру в соответствии с тем, что указано в политике хранения, связанной с объектом или виртуальной машиной. Другими словами, если политика FTT=1 и RAID-1, то вы увидите две копии данных. Если политика определяет, что данные должны быть растянуты между локациями и защищены RAID-5 в каждой локации, тогда вы увидите конфигурацию RAID-1 между сайтами и конфигурацию RAID-5 внутри каждого сайта. Поскольку снапшоты vSAN ESA являются неотъемлемой частью объекта, они автоматически следуют всем требованиям, определенным в политике. Другими словами, если политика установлена как "stretched", то снимок также будет автоматически растянутым.

Есть один нюанс, который автор хочет отметить, и для этого нужно показать диаграмму:

На диаграмме ниже показан модуль Data Protection Appliance, также известный как менеджер снимков (snapshot manager appliance). Как вы видите, на диаграмме указано "метаданные отделены от модуля" (metadata decoupled from appliance), и оно как-то связано с объектом глобального пространства имен. Этот объект глобального пространства имен хранит все детали защищенных виртуальных машин (и не только). Как вы можете догадаться, как менеджер снимков, так и объект глобального пространства имен должны также быть растянутыми. Для объекта глобального пространства имен это означает, что вам нужно убедиться, что политика по умолчанию для хранилища данных установлена как "stretched", и, конечно, для менеджера снапшотов вы можете просто выбрать правильную политику при его развертывании. В любом случае убедитесь, что политика по умолчанию для хранилища данных соответствует политике аварийного восстановления и защиты данных.

В этом демо-ролике, представленном компанией VMware, демонстрируется, как можно использовать VMware vDefend для блокировки небезопасных протоколов и защиты рабочих нагрузок в корпоративной инфраструктуре от потенциальных угроз.

Проблема небезопасных протоколов

Небезопасные протоколы, такие как SMB версии 1, могут быть уязвимы для атак. Например, уязвимость SMBv1 может позволить злоумышленнику получить доступ к виртуальной машине, если система не была своевременно обновлена. Проблема может усугубляться тем, что в некоторых случаях обновление системы невозможно из-за бизнес-ограничений.

Для демонстрации в видео используются две машины:

• Windows 7 с включенным SMBv1, которая не предназначена для предоставления файловых сервисов.
• Windows Server 2016, выступающий в роли файлового сервера, который хранит конфиденциальные данные компании.

Обе машины не обновлялись, что делает их уязвимыми для эксплоита EternalRomance. Эта уязвимость позволяет злоумышленнику получить доступ к системе, после чего он может похитить данные или перемещаться по сети, атакуя другие машины.

Как VMware vDefend защищает инфраструктуру

1. Ограничение доступа с использованием брандмауэра (DFW)

В первую очередь, демонстрируется, как злоумышленник использует уязвимость на машине с Windows 7, которая не является файловым сервером, но продолжает принимать SMB-трафик. После успешного взлома злоумышленник получает неограниченный доступ к системе.

Чтобы предотвратить подобные атаки, с помощью VMware vDefend создается правило, которое ограничивает доступ к сервисам SMB только для нужных диапазонов IP-адресов (RFC 1918 в этом примере). Все остальные подключения, использующие SMB, будут заблокированы. Таким образом, злоумышленник больше не может воспользоваться уязвимостью Windows 7, и попытка повторного взлома завершается неудачей.

2. Защита файлового сервера с использованием Intrusion Detection and Prevention (IDP)

Вторая часть видео фокусируется на защите Windows Server 2016. Поскольку файловый сервер должен продолжать предоставлять доступ к конфиденциальным данным, простое блокирование SMB не подходит. Для этого используется система обнаружения и предотвращения вторжений (IDP), которая контролирует трафик и блокирует вредоносные пакеты.

Для защиты сервера создается специальный профиль, который отслеживает все попытки проникновения через протокол SMB и, при обнаружении подозрительного трафика, блокирует его. В случае атаки трафик блокируется, и вредоносное ПО не может выполнить свои действия, предотвращая эксплуатацию системы.

Мониторинг событий и дальнейшие действия

После блокировки атаки администраторы могут использовать встроенные инструменты мониторинга для детального анализа инцидента. В VMware vDefend доступны такие данные, как IP-адреса источников, целевые машины, идентификаторы сигнатур атак и другие полезные сведения, которые можно передать в команду безопасности (SOC) для дальнейшего расследования.

Также можно экспортировать захваченные пакеты для их анализа в сторонних программах, таких как Wireshark, что позволяет точно выяснить, какие данные пытался отправить злоумышленник.

VMware vDefend предоставляет мощные инструменты для защиты рабочих нагрузок от небезопасных протоколов, предотвращая эксплуатацию уязвимостей, боковое перемещение злоумышленников в сети и утечку данных. В видео выше демонстрируется, как можно комбинировать функции брандмауэра и системы предотвращения вторжений для обеспечения всесторонней безопасности корпоративной инфраструктуры.